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Conference on Object-Oriented Programming 
Systems, Languages, and Applications 


OOPSLA is the premier forum bringing together 
researchers, developers and practitioners to share 
ideas and experiences related to object 
technology. The OOPSLA ’92 conference will 
feature technical papers, panel discussions, 
tutorials, workshops, experience reports, 
technical demonstrations, poster sessions, a 
one-day educator’s symposium plus an exhibition 
of object-technology products and services. Join 
us in Vancouver. 



Registration/Conference Information 

An advance program brochure containing tutorial 
information, registration forms, housing 
information, and preliminary technical program 
information will be mailed in June 1992. If you 
attended the 1990 or 1991 OOPSLA Conferences or 
if you are a member of ACM/SIGPLAN, you will 
automatically receive a copy of the advance 
program brochure. Otherwise, please contact: 


18-22 October 1992 
Vancouver Trade & 
Convention Centre 
Vancouver, 

British Columbia, 
Canada 



Carole Mann 

OOPSLA ’92 Registration Chair 
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2060 Goldwater Court 
Maitland, FL 32751 
Phone: +1-407-628-3602 
Fax: +1-407-628-3186 

Email: mann@eola.cs.ucf.edu 
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LANNET II.5 
Local Area Networks 



COMNET II.5 
Wide Area Networks 



New for local or wide area 
network analysts 

Free trial and, if you act now, free training 


L ANNET 11.5 uses simulation to predict 
your LAN performance. You simply 
describe your LAN and workload. 

Animated simulation follows immediately 
--no programming. 

Easy-to-understand results 

You get an animated picture of your LAN. 
System bottlenecks and changing levels of 
utilization are apparent. 

Your reports show LAN statistics such as 
transfer times, delays, and queues. Client, server, 
and gateway statistics show queue lengths, 
waiting times, and messages sent. 

Your LAN simulated 

You can predict the performance of any LAN. 
Industry standard protocols such as Ethernet, 
Token Ring, Token Bus, FDDI, and lOBase-T 
are built-in. Variations can be modeled. 


C OMNET II.5 uses simulation to predict 
your network performance. You simply 
describe your network, traffic load, and routing. 

Animated simulation follows immediately 
--no programming. 

Easy-to-understand results 

You get an animated picture of your network. 
Routing choices and changing levels of network 
utilization are apparent. 

Your reports show response times, blocking 
probabilities, call queueing and packet delays, 
network throughput, circuit group utilization, 
and circuit group queue statistics. 

Your network simulated 

You can include LAN’s and multidrop lines in 
your model. X.25, SNA, DECnet, ISDN, SS7, 
fast packet, TCP/IP, token passing, and 
CSMA/CD are easily modeled. 


Free Trial Offer 

The free trial contains everything you need to 
try LANNET II.5™ or COMNET II.5® on 
your PC, Workstation, or Mainframe. Act now 
for free training-no cost, no obligation. 

For immediate information 

For LANNET II.5 call Eric Chapman, or for 
COMNET II.5 call Chris LeBaron, at (619) 
457-9681, Fax (619) 457-1184. In Europe, call 
Nigel McNamara, in the UK, on 0276 671 671, 
Fax 0276 670 677. In Canada, call Peter Holt on 
(613) 782-2474, Fax (613) 782-2202. 

University faculty should call about our 
special offer for research and teaching. Mfe c 


Rush free trial and training information for: 
□ LANNET II.5 □ COMNET II.5 
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Qj Sharing Perspectives 

ACM 1992 Conference on 
Computer Supported Cooperative Work 

October 31 - November 4,1992 

Toronto, Canada 

You are invited to attend tfie ACM 1992 Conference on Computer Supported 
Cooperative Work (CSCW '92). CSCW combines communications ond computing 
technology to support work and other activities in groups. The conference includes 
theory and research in: computer and communications systems, the nature of 
group and organizational work, and the development and use of CSCW systems. 
The theme of Sharing Perspectives will explore links between technological and 
behavioural perspectives, design and use of systems, and theory ond practice. 


Program highlights 


Tutorials 

Sunday November 1, 1992 

Tutorials by leading researchers and practitioners offer in-depth coverage of 
important topics including: 

CSCW ond Groupware: Overview of Behavioural Issues and Survey of Systems 

Jonathan Grudin— University of California, Irvine 
Steven Poltrock— Boeing Computer Services 

Computer-supported Meeting Rooms 

Lisa Neal— EDS Center for Advanced Research 

Building CSCW Interfaces 

Alan Wexelblaf— Bull Information Systems 

Ethnography and System Development 

David Randall and Richard Bentley— Lancaster University 

The Role of Hypermedia for CSCW Applications 

Norbert A. Streitz— integrated Publication and Information Systems institute, (GMD-IPSI) 

Networks for Collaboration: Video/AudioConferencing 

Robert Fish and Robert Kraut— Bellcore 

MIME: Enhanced Internet Mail Standard as an Application Base for CSCW 

Nathaniel S. Borenstein— Bellcore 

Strategies for Encouraging Adoption of Group Technologies 

Susan E. Rudman—i/S West 
Ellen Francik— Pacific Bell 

Workshops 

Workshops will be held on Saturday October 31,1992. 

Demonstrations and videos 

Demonstrations and videos will be held on Monday November 2 - Wednesday 
November 4,1992. 

CSCW '92 is sponsored by the Association for Computing Machinery Special Interest Group on Computer-Human 
Interaction (SIGCHI) and Special Interest Group on Office Information Systems (SIGOIS). 


Plenaries, papers, and panels 

Monday November 2 - Wednesday November 4, 1992 

Opening Plenary 

Shumpei Kumon— Center for Global Communicabons, International University of Japan 

Papers 

Themes for papers include: 

— Video Spaces 

— Building Realtime Groupware 

— Innovations in Email 

— Collaborative Writing 

— Ethnographically Informed Design 

— Conversational Props 

— CSCW Architectures 

— The Power of Simple Shared 
Workspaces 

Panels 

Panels will bring together different perspectives on: 

— Commercial Products for CSCW — CSCW and the Paradox of Stalled 

— Privacy Issues and CSCW Productivity 

For complete conference information, contact: 

CSCW '92 Email: cscw92@dgp.foronto.edu 

University of Toronto Phone: (416) 978-5184 

Computer Systems Research Institute Fax: (416) 978-0458 
6 King's College Road 
Toronto, Ontario, Canada M5S1A1 


— Multimedia Systems 

— Consistency in Collaborative Systems 

— Time as an Issue in CSCW 

— Tools for Coordination Processes 

— Field Studies in Coordination 

— Collaboration in the Real World 

— Domain Specific Collaborative Tools 

— Organizational Influences on CSCW 
Success 
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1991 financial results 


The IEEE Computer Society was 
not immune to the severe changes in 
the general world economy and the 
computer industry in 1991. Although 
the Board of Governors had adopted 
a budget that provided for rebuilding 
our reserve funds, revenues were 
down more sharply than anticipated. 
Substantial reductions in expenses, 
over and above those accomplished in 
1989 and 1990, were insufficient to 
avoid a substantial deficit. Even fur¬ 
ther cost reductions were considered, 
but it was felt that these could have 
damaged critical society programs. 

Following this report are the audit¬ 


ed financial statements for the society 
for 1991 prepared by Coopers and Ly- 
brand. The final figures show an oper¬ 
ating deficit of $490,800. This loss es¬ 
sentially eliminated the liquid 
reserves necessary to maintain society 
programs through difficult financial 
years. As a result, it is imperative that 
budget surpluses be generated over 
the next few years that will restore 
our reserve position and ensure the 
continued financial health of the soci¬ 
ety. 

As of May 1992, it seems that the fi¬ 
nancial environment has at least be¬ 
come neutral, if not positive. The bud¬ 


get for 1992 is projected to result in a 
modest surplus. More critically, the 
Board of Governors has set the bud¬ 
get targets for 1993-94 to repair the fi¬ 
nancial erosion of 1989-91. 

Through a small increase in the 
member fee, modest price increases 
for some member programs, and very 
substantial increases in nonmember 
periodical prices, and through stead¬ 
fastly holding the line on expenses, 
the aggressive targets for 1993 and 
1994 can be achieved without reduc¬ 
ing member programs and services. In 
fact, the society will maintain present 
programs, as well as increase the num- 



Figure 1. Computer Society income structure; 1991 total 
income, $19.5 million. 


Figure 2. Computer Society expense structure; 1991 to¬ 
tal expenses, $20.0 million. 
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Report of independent accountants 


ber of pages in current publications, 
initiate new conferences and publica¬ 
tions, and stimulate other technical 
activities and member services while 
providing for improved financial 
health. 

The society will start two new 
transactions and one new magazine 
in 1993. Both transactions are being 
developed with partners: IEEE 
Transactions on Networking in part¬ 
nership with the IEEE Communica¬ 
tions Society and the ACM and 
IEEE Transactions on VLSI in part¬ 
nership with the IEEE Circuits and 
Systems Society and the Solid State 
Circuits Council. The new magazine, 
IEEE Parallel and Distributed Tech¬ 
nology, will provide an exciting com¬ 
plement to our transactions in that 
area. Each of these publications is 
viewed as an addition to improve our 
coverage of technical areas that are 
of great interest to our members. 
Current publications will also see en¬ 
hancements that will improve their 
value to members; increases in the 
number of pages are planned for 
over half of them. 

Figures 1 and 2 (preceding page) 
present an overview of the income 
sources and expense areas for the so¬ 
ciety. The graph of income structure 
for 1991 shows that we have multi¬ 
ple, diverse sources of income so that 
we are not dependent on any one 
source of income. The graph of ex¬ 
pense structure shows that the large 
majority of funds are spent directly 
on member programs and services 
and the volunteer and staff organiza¬ 
tion required to support those pro¬ 
grams and services. Funds used for 
staff salaries and benefits, and other 
related expenses, remain substantial¬ 
ly smaller than is typical for similar 
organizations. This reflects the fact 
that we remain a volunteer-driven 
organization, using staff to assist vol¬ 
unteers in getting the work of the so¬ 
ciety accomplished. Strong volunteer 
participation is the main contributor 
to adding new activities, not the abil¬ 
ity to hire and pay additional staff. 

The goal of the Computer Soci¬ 
ety’s volunteer and staff leaders re¬ 
mains that of providing services of 
professional value to our members 
and the profession while ensuring the 
continued financial health of the or¬ 
ganization. Although the 1993 bud¬ 
get will not be adopted until Novem¬ 
ber, the plans for 1993 and 1994 
being prepared now provide the 
blueprint for achieving this goal. 

Laurel Kaleda, treasurer 

IEEE Computer Society 


Board of Governors of the 
IEEE Computer Society: 

We have audited the accompanying 
balance sheets of the IEEE Computer 
Society (the society) as of December 


31,1991 and 1990, and the related 
statements of revenue, expenses, and 
changes in fund balances for the years 
then ended. These financial state¬ 
ments are the responsibility of the so¬ 
ciety’s management. Our responsibili- 


IEEE Computer Society Balance Sheets 
December 31,1991 and 1990 


ASSETS 

1991 

1990 

Current assets: 

Cash, including interest-bearing accounts 

$ 326,700 

$ 195,300 

Investments (Note 3) 

Accounts receivable, less allowance 
for doubtful accounts of $96,700 

2,011,400 

1,116,500 

in 1991 and $79,600 in 1990 

Receivable from Institute of Electrical 

935,600 

1,647,100 

and Electronics Engineers, Inc. (Note 7) 

252,700 

252,200 

Conference receivables 

168,000 

443,800 

Conference advances 

558,200 

266,600 

Inventory (Note 2) 

748,800 

887,200 

Prepaid expenses and other assets 

622,000 

497.000 

Total current assets 

5,623,400 

5,305,700 

Fixed assets, net (Notes 2, 4 and 5) 

3,507,000 

3,682,500 

Total assets 

LIABILITIES AND FUND BALANCES 

$ 9,130,400 

$ 8,988,200 

Current liabilities: 

Current portion of long-term debt (Note 5) $ 1,451,100 

$ 79,700 

Accounts payable and accrued expenses 
Deferred income: 

1,726,100 

1,387,400 

Membership fees and subscriptions 

3,465,400 

3,138,900 

Advertising and other 

170,200 

122,500 

Total current liabilities 

6,812,800 

4,728,500 

Long-term debt, less current portion (Note 5) 

- 

1,451,300 

Total liabilities 

6,812,800 

6,179,800 

Fund balances: 

Undesignated 

Designated, primarily for technical 

2,317,600 

2,703,400 

committees (Note 8) 

- 

105,000 

Total fund balances 

2,317,600 

2,808,400 

Total liabilities and 

fund balances 

$ 9,130,400 

$ 8,988,200 
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ty is to express an opinion on these fi¬ 
nancial statements based on our audits. 

We conducted our audits in accor¬ 
dance with generally accepted audit¬ 
ing standards. Those standards re¬ 
quire that we plan and perform the 
audit to obtain reasonable assurance 
about whether the financial state¬ 
ments are free of material misstate¬ 
ment. An audit includes examining, 
on a test basis, evidence supporting 
the amounts and disclosures in the fi¬ 
nancial statements. An audit also in¬ 
cludes assessing the accounting princi¬ 
ples used and significant estimates 
made by management, as well as eval¬ 
uating the overall financial statement 
presentation. We believe that our au¬ 
dits provide a reasonable basis for our 
opinion. 

In our opinion, the financial state¬ 
ments referred to above present fairly, 
in all material respects, the financial 
position of the IEEE Computer Soci¬ 
ety as of December 31,1991 and 1990, 
and the results of its operations for 
the years then ended, in conformity 


with generally accepted accounting 
principles. 

Coopers & Lybrand 

Washington, D.C. 

March 27,1992 

Notes to financial 
statements 

1. Organization and purpose 

The IEEE Computer Society (the 
society) is organized within the Insti¬ 
tute of Electrical and Electronics En¬ 
gineers, Inc. (IEEE), an organization 
exempt from income tax, pursuant to 
Internal Revenue Code Section 
501(c)(6). Within the bylaws of IEEE, 
delegation of the responsibility for the 
society’s operations has been placed 
with the society’s Board of Governors 
and Executive Committee. The soci¬ 
ety’s constitution states that “The so¬ 
ciety shall be scientific, literary, and 


educational in character. The society 
shall strive to advance the theory, 
practice, and application of computer 
and information processing science 
and technology and shall maintain a 
high professional standing among its 
members. The society shall promote 
cooperation and exchange of technical 
information among its members and 
to this end shall hold meetings for the 
presentation and discussion of techni¬ 
cal papers; shall publish technical 
journals; and shall, through its organi¬ 
zation and other appropriate means, 
provide for the needs of its members.” 

2. Summary of significant accounting 
policies 

Reporting entity 

The accompanying financial state¬ 
ments include all society accounts 
maintained at the society’s offices in 
Washington, D.C.; Los Alamitos, Cal¬ 
ifornia; Brussels, Belgium; Tokyo, Ja¬ 
pan; and certain accounts maintained 
at IEEE Headquarters. The accompa¬ 
nying financial statements do not in¬ 
clude the accounts of society chapters 
which operate directly under IEEE. 

Income recognition 

Income from annual membership 
fees and periodical subscriptions is 
recognized during the year to which it 
pertains. The society’s share of reve¬ 
nue and expenses for conferences par¬ 
tially or entirely sponsored by the so¬ 
ciety is generally recognized in the 
year in which the conference is held. 

Functional allocation of expenses 

The costs of various society activi¬ 
ties have been accounted for on a 
functional basis in the statements of 
revenue, expenses and changes in 
fund balances. Accordingly, certain 
costs have been allocated among the 
various activities and administration. 

Inventory 

Inventory consists of tutorial books 
and standards published by the soci¬ 
ety and is stated at the lower of cost 
or net realizable value. Cost is deter¬ 
mined on an average cost basis. 

Fixed assets and depreciation 

Fixed assets are recorded at cost 
when purchased. The society provides 
for depreciation of fixed assets by 
charges to expense at rates considered 
adequate to amortize the cost of such 
assets over their estimated useful lives 
(5 to 10 years for office furniture and 
equipment; 30 and 35 years for build¬ 
ings) on a straight-line basis. 

When fixed assets are retired or 


IEEE Computer Society 

Statements of Revenue, Expenses and Changes in Fund Balances 
for the years ended December 31,1991 and 1990 



1991 

1990 

Revenue: 

Computer Society membership fees 
Periodical subscriptions and 

$ 1,779,800 

$ 1,531,200 

other publication activities 
Conventions, conferences and 

11,438,200 

11,732,000 

other technical activities 

5,853,100 

6,322,700 

Interest income (Note 3) 

88,700 

100,100 

Other income 

365,600 

581,300 

Total revenue 

19,525,400 

20,267,300 

Expenses: 

Periodical and publication activities 
Conventions, conferences and 

10,707,100 

10,727,436 

other technical activities 

5,671,200 

5,515,764 

Administration 

3,637,900 

3,908,900 

Total expenses 

20,016,200 

20,152,100 

Excess (deficiency) of 

revenue over expenses 

(490,800) 

115,200 

Fund balances at beginning of year 

2,808,400 

2,693,200 

Fund balances at end of year 

$ 2,317,600 

$ 2,808,400 
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Table 1. Fixed assets as of December 31,1991 and 1990. 



1991 

1990 

Land 

Buildings and improvements 
Office furniture and equipment 

$ 1,334,400 
2,023,200 
1,417,900 

$ 1,334,400 

1,995,700 
1,409,500 


$ 4,775,500 

4,739,600 

Accumulated depreciation 

(1,268,500) 

(1,057,100) 


$ 3,507,000 

$ 3,682,500 


Table 2. Notes payable as of December 31,1991 and 1990. 



Annual 

interest 

1991 

1990 

Note payable, 
balance due on 
September 21,1997 

Prime + 

2 .15% 

$ 1,409,500 

$1,434,000 

Note payable, 
balance due on 
September 25,1992 

9.50% 

41,600 

97,000 

Less: Amount due within 

one year (see Note 5) 

1,451,100 

1,451,100 

1,531,000 

79,700 



$ — 

$ 1,451,300 


otherwise disposed of, the property 
and accumulated depreciation ac¬ 
counts are reduced by the applicable 
amounts and any gain or loss is re¬ 
flected in income. 

3. Investments 

Investments, which are stated at 
cost, consist of unrestricted funds in¬ 
vested with IEEE. The society has in¬ 
vested such funds under an option 
whereby the average monthly balance 
earns a rate equal to the 60-day 
United States Treasury bill rate, 
which is guaranteed by IEEE. 

4. Fixed assets 

Fixed assets as of December 31 are 
shown in Table 1. 

Depreciation expense was $331,400 
and $299,500 in 1991 and 1990, re¬ 
spectively. 

5. Notes payable 

Notes payable as of December 31 
are shown in Table 2. 

The note payable, due September 
21,1997, is collateralized by a first 
lien deed of trust on the Washington, 
D.C. property. Principal is paid 
monthly in graduated amounts, to¬ 
gether with interest, through the term 
of the note, with the remaining princi¬ 
pal balance due on September 21, 
1997. 

During 1991, the Computer Society 
transferred its primary operating 
bank account from Maryland Nation¬ 
al Bank (MNB) to Citizens Bank. The 
loss reported by MNB in fiscal year 
1990 precipitated this action. Al¬ 
though the society has made, and con¬ 
tinues to make, timely payments on 
its mortgage note, movement of the 
operating account technically consti¬ 
tuted an event of default under Arti¬ 
cle III, Section 3.12 of the deed of 
trust. The bank subsequently exer¬ 
cised its option, under the agreement, 
to raise the stated interested rate by 2 
percent. 

The society is currently negotiating 
a refinancing of this mortgage 
through the IEEE. The IEEE has a 
proposal from its bank to lend the 
Computer Society $1.5 million at an 
interest rate equal to 140 basis points 
over the five-year Treasury Note rate 
to be fixed at the time of closing. The 
term of the note is expected to be five 
years with a twenty-year amortiza¬ 
tion. There are no penalties associat¬ 
ed with the prepayment of the soci¬ 
ety's existing note, given proper 
notice. 

The note payable, due September 


25,1992, is collateralized by certain 
equipment which was purchased with 
the proceeds of the note. Repayment 
is made in equal monthly principal in¬ 
stallments of $4,616, plus interest, 
with the remaining balance payable 
on September 25,1992. 

Interest expense relating to all of 
the above notes amounted to $135,700 
and $151,600 in 1991 and 1990, re¬ 
spectively. 

6. Pension plan 

The society participates in a de- 
fined-benefit pension plan sponsored 
by IEEE. The IEEE plan covers sub¬ 
stantially all IEEE employees, includ¬ 
ing those of the society. It is the poli¬ 
cy of IEEE to fund pension costs 
accrued. 


Statement of Financial Account¬ 
ing Standards (SFAS) No. 87, “Em¬ 
ployers Accounting for Pensions,” 
requires that certain disclosures be 
made of the actuarial present value 
of benefit obligations, the projected 
benefit obligation, the fair value of 
the available plan assets, and the ac¬ 
crued pension costs. Such disclo¬ 
sures are not presented for the soci¬ 
ety because the structure of the 
IEEE plan does not readily permit 
the plan’s assets and benefit obliga¬ 
tion data to be determined for each 
individual society. Based upon actu¬ 
arial valuations of the IEEE plan, 
assuming a discount rate and an ex¬ 
pected long-term rate of return on 
assets of 7.00 percent and 7.75 per¬ 
cent in 1991 and 1990, respectively, 
and an increase in the level of com- 
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pensation of 4.5 percent and 5.25 per¬ 
cent in 1991 and 1990, respectively, 
the IEEE plan assets exceeded the 
projected benefit obligation at De¬ 
cember 31,1991 and 1990. The 
IEEE’s funding policy is to contribute 
amounts at least equal to the mini¬ 
mum funding requirements of the 
Employee Retirement Income Securi¬ 
ty Act of 1984 (ERISA) and limits 
such contributions to amounts no 
greater than those computed under 
the full-funding limitations of the In¬ 
ternal Revenue Code. The society was 
allocated $73,100 of pension expense 
in 1991 and $38,000 in 1990. 

7. Related-party transactions 

Certain general and administrative 
expenses incurred by IEEE Head¬ 
quarters and charged to the society 
amounted to $1,172,000 in 1991 and 
$1,043,400 in 1990. In addition, the so¬ 
ciety sells published materials to 
IEEE. Such sales amounted to 
$314,700 in 1991 and $393,700 in 1990. 
Other transactions undertaken in the 
normal course of business between the 
society and IEEE have been reflected 
in the society’s financial statements. 

8. Designated fund balance 

As of December 31,1990, the 
Board of Governors designated a 
maximum of $105,000 from confer¬ 
ence surpluses to be available for 
technical committee use during 1991. 
In January 1991, all remaining techni¬ 
cal committee surpluses reverted to 
undesignated fund balances. 

9. Lease commitments 

The society leases certain office 
space and equipment under long-term 
leases. Certain leases contain renewal 
provisions or may require payment of 
taxes, maintenance, and repair costs. 
Future minimum rental payments un¬ 
der leases having initial or remaining 
lease terms in excess of one year are 
as follows: 

1992 

1993 

1994 

1995 

1996 


Total 


$ 100,000 
100,000 
100,000 
71,000 
6,000 

$ 377,000 


Rent expense was $159,000 and 
$93,000 for the years ended December 
31,1991 and 1990, respectively. 


August 1992 


2 nd SEI Conference on 

Software Risk 


& Practitioners 


Considerations The Second SEI Conference on Issues in Software Risk 
for Managers will be held in Pittsburgh in March 2-4 of 1993. The confer- 
brings together software managers, practitioners, and 
educators to discuss software technical risk. The conference 
will include plenary sessions, formal invited and contributed 
presentations, panel discussions, and informal birds-of-a- 
feather meetings. Vendor exhibits will also be offered. 

Individuals or teams interested in making a 45 minute 
presentation (including questions and discussions) must 
submit a 2000 to 3000 word abstract and a brief biography to 
the general chair, George Pandelios. Preference will be given 
to submissions that demonstrate results of the application of 
risk management in software development projects. 

Extended abstracts are due no later than October 31, 1992. 
Accepted presenters will be notified by November 13,1992. 


George Pandelios Phone: 412 / 268-7186 

Software Engineering Institute Fax: 412 / 268-5758 
Carnegie Mellon University Internet: gjp@sei.cmu.ec 

Pittsburgh, PA 15213-3890 


Moving ? 


Name (Please Print) 


New Address 


PLEASE NOTIFY 
US 4 WEEKS IN 
ADVANCE 


City State/Country Zip 


MAIL TO: 

IEEE Service Center 
445 Hoes Lane 
Piscataway, NJ 08854 


• This notice of address change will apply to all 
ATTACH IEEE publications to which you subscribe. 

LABEL . Lj St new address above. 

HERE 

• If you have a question about your subscription, 
place label here and clip this form to your letter. 


























Parallel Programming 
Using Shared Objects 
and Broadcasting 

Andrew S. Tanenbaum, M. Frans Kaashoek, Henri E. Bal 
Vrije Universiteit, Amsterdam 


A s computers have become less expensive, interest in linking multiple 
! CPUs to build powerful distributed and parallel systems has increased. 
The goal is to achieve high performance at low cost. 

In this article, we first survey the two major design approaches taken so far — 
multiprocessors and multicomputers — and point out their strengths and weak¬ 
nesses. Then we introduce a hybrid form that employs an unusual software 
organization on conventional hardware to achieve a system that is easy both to 
program and to build. The essence of our approach is to implement reliable 
broadcasting as a distinct semantic layer and use this layer to implement shared 
objects. 

Orca, a new parallel programming language based on distributed shared objects, 
uses this reliable broadcast mechanism and has been used to develop applications 
for a prototype system. For applications with a high read/write ratio to shared 
objects, our approach frequently achieves close to linear speedup. 


Parallel computers 
come with or 
without shared 
memory. One is hard 
to build, the other 
hard to program. A 
hybrid form combines 
the best properties 
of each. 


Multiprocessors 

Systems with multiple processors can be divided into two categories: those that 
contain physical shared memory, called multiprocessors, and those that do not, 
called multicomputers. Multiprocessors have a single, global, shared address space 
visible to all processors. Any processor can read or write any word in the address 
space by simply moving data from or to a memory address. Communication is via 
the shared memory. Multicomputers do not have shared memory and must 
communicate by message passing. 

The key property required of any multiprocessor is memory coherence: When 
any processor writes a value v to memory address m, any other processor that 
subsequently reads the word at memory address m, no matter how quickly after the 
write, will get the value v just written. 

Multiprocessor hardware. There are two basic ways to build a multiprocessor, 
both of them expensive. The first way is to put all the processors on a single bus 
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Figure 1: Three multiprocessor designs: (a) single bus, (b) crossbar switch, and (c) omega network. C indicates CPU 
(possibly with cache); M indicates memory module. 


along with a memory module. To read 
or write a word of data, a processor 
makes a normal memory request over 
the bus. Since there is only one memory 
module and there are no copies of mem¬ 
ory words anywhere else, the memory is 
always coherent. To reduce the amount 
of bus traffic, the processors are usually 
equipped with a cache for storing copies 
of the most recently accessed memory 
words. The caches are kept consistent 
by special hardware that monitors bus 
traffic and updates or invalidates copies 
of words that are about to be modified 
by another processor. Figure la shows a 
bus-based multiprocessor. 

The second approach to building a 
multiprocessor uses some kind of switch¬ 
ing network, such as the crossbar switch 
shown in Figure lb. In this organiza¬ 
tion, each of the n processors can poten¬ 
tially be connected to any one of the n 
memory banks via a matrix of electron¬ 
ic switches. When switch ij is closed (by 
hardware), processor i is connected to 
memory bank j and can read or write 
data there. The problem with the cross¬ 
bar switch is that connecting n proces¬ 
sors to n memory banks requires n 2 
switches. As n becomes large, say, 1,024 
processors and 1,024 memories, the 
switch becomes prohibitively expensive 
and unmanageable. 

An alternative switching scheme uses 
a network, for example, the omega net¬ 
work shown in Figure lc. The omega 
network, a sophisticated hardware 
switching network, connects the CPUs 
and the memories. To read a word of 
memory, a CPU sends a request packet 
to the appropriate memory via the 
switching network, which sends the re¬ 


ply back the other way. The problem 
with this approach lies in the substantial 
delay incurred and the large number 
(nlog 2 n) of switches needed. 

Multiprocessor software. In contrast 
to multiprocessor hardware, which for 
large systems is complicated, difficult to 
build, and expensive, multiprocessor 
software is straightforward. Since all 
processes run within a single shared 
address space, they can easily share data 
structures and variables. When one pro¬ 
cess updates a variable and another one 
reads it immediately afterward, the read¬ 
er always gets the value just stored (the 
memory coherence property). 

To avoid chaos, cooperating process¬ 
es must synchronize their activities. For 
example, while one process is updating 
a linked list, it is essential that no other 
process even attempt to read the list, let 
alone modify it. The many well-known 
techniques for providing synchroniza¬ 
tion include spin locks, semaphores, and 
monitors. These are discussed in any 
standard operating-systems textbook. 
These techniques provide easy, inex¬ 


pensive sharing using a methodology 
that has been around for years and is 
well understood. 

Multicomputers 

In contrast to multiprocessors, which 
by definition share primary memory, 
each CPU in a multicomputer has its 
own private memory, which it alone can 
read and write. This difference leads to 
a significantly different architecture in 
both hardware and software. 

Multicomputer hardware. As with 
multiprocessors, there are various in¬ 
terconnection schemes for multicom¬ 
puters. Figure 2 shows three schemes. 
In a simple bus-based multicomputer 
(Figure 2a), each CPU has its own local 
memory, which is not accessible by the 
others. A grid architecture (Figure 2b), 
which is easy to understand and lay out 
on a printed circuit board or chip, is best 
suited to two-dimensional problems such 
as graph theory and vision. A hyper¬ 
cube is a k-dimensional cube. One can 
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imagine a four-dimensional hypercube 
as a pair of ordinary cubes with the 
corresponding vertices connected, as 
shown in Figure 2c (the lower left nodes 
at the rear have been omitted for clari¬ 
ty). In a hypercube, the number of con¬ 
nections to each processor grows loga¬ 
rithmically with the number of CPUs, 
but the worst-case delay is also logarith¬ 
mic. With a grid, the delay grows as the 
square root of the number of proces¬ 
sors, which is much worse for large sys¬ 
tems. 

Multicomputer software. Since, by 
definition, multicomputers do not 
share memory, they communicate by 
message passing. The simplest of the 
software paradigms that express mes¬ 
sage passing has two operating system 
primitives, Send and Receive. The many 
variations on this theme include block¬ 
ing or nonblocking and buffered or non- 
buffered. 

A serious problem with message pass¬ 
ing is that, conceptually, it is really in¬ 
put/output and thus complicates pro¬ 
gramming. While all programs do it, 
input/output does not have the abstrac¬ 
tion power of, say, procedures or ab¬ 
stract data types on which to build a 
system. In most programming languag¬ 
es it is almost an afterthought. To hide 
the bare input/output, Birrell and Nel¬ 
son 1 proposed a scheme, called remote 
procedure call, that hides message pass¬ 
ing to a limited extent. With RPC, the 
caller calls a stub (library) routine, which 
sends the message. Nevertheless, RPC 
introduces its own problems. It restricts 
the use of general pointers and global 
variables, makes the use of array pa¬ 
rameters very expensive, and requires 
programmers to deal with complex fail¬ 
ure semantics. 

Distributed shared 
memory 

Various researchers have proposed 
intermediate designs to capture the de¬ 
sirable properties of both multiproces¬ 
sor and multicomputer architectures. 
Most of these designs attempt to simu¬ 
late shared memory on multicomput¬ 
ers. In all of them, any executing pro¬ 
cess can access data from its own memory 
without delay, whereas access to data 
located on another machine entails con¬ 
siderable delay and overhead because a 


request message must be sent and a 
reply received. 

A system in which otherwise disjoint 
machines share a single address space is 
said to have a distributed shared mem¬ 
ory. In its simplest form, the shared 
memory is divided into fixed-size pages, 
with each page residing on exactly one 
processor. Processor references to a lo¬ 
cal page are done by hardware in the 
usual way. However, referencing a re¬ 
mote page causes a page fault and a trap 
to the operating system. The operating 
system fetches the page just as it would 
in a traditional virtual memory system, 
except that the page is fetched from 
another processor (which loses the page) 
instead of from the disk. 

A significant improvement to the ba¬ 
sic algorithm has been proposed, imple¬ 
mented, and analyzed by Li and Hudak. 2 
Their design reduces thrashing (page 
traffic caused by concurrent readers) by 
permitting replication of read-only pages 
on all the machines that need them. 
When a read-only page is referenced, a 
copy of the page is made and sent, so the 
original owner may continue using the 
page. Li and Hudak have also presented 
several algorithms, both centralized and 
distributed, for locating pages. 

Another approach is to weaken the 
semantics of the shared memory. Ghara- 
chorloo et al. proposed it for multipro¬ 
cessors, 3 but, as shown by Bennet, Cart¬ 
er and Zwaenepoel, 4 it can be applied to 
distributed shared memory. The advan¬ 
tage is greater efficiency, but the price is 
more complexity for the programmer. 
It is simpler for the programmer to think 
of a read as always returning the most 
recently written value. Making this true 
only under certain conditions increases 
the possibility of subtle errors. 

A completely different approach is to 
base the sharing not on pages, but on 
more software-oriented concepts. In 
Linda, 5 for example, an abstract tuple 
space is shared. Operations are avail¬ 
able to insert and delete tuples from this 
space. 

Another approach is to share objects, 
that is, abstract data types on which a 
set of well-defined operations are possi¬ 
ble. Emerald illustrates this method. 6 
Emerald programs can perform opera¬ 
tions on objects without regard to pro¬ 
gram and object location. 

Although the tuple-based and object- 
based schemes are conceptually simple, 
both suffer from performance problems 
due to the considerable amount of net¬ 


work traffic. This point is one addressed 
by our approach, which we believe is an 
advance over previous methods. 

Our design’s four layers 

In our research, we have devised and 
implemented an alternative model based 
on abstract data types. This model pre¬ 
serves the coherency of object-based 
shared memory. It has simple semantics 
and can be implemented efficiently. It is 
the basis of our new parallel program¬ 
ming language, Orca, and is implement¬ 
ed through reliable broadcasting. It con¬ 
sists of four layers, as shown in Figure 3. 

Layer 1. The first layer is the bare 
CPU and networking hardware. Our 
scheme is primarily intended for net¬ 
works that support broadcasting (send¬ 
ing a message to all machines) or multi¬ 
casting (sending a message to a selected 
group of machines) in hardware. Ether¬ 
net, earth satellites, and cellular radio 
are examples of broadcasting or multi¬ 
casting networks. (For simplicity, we’ll 
use the term “broadcasting” to mean 
either one.) Broadcasting is assumed to 
be unreliable; that is, messages can be 
lost. 

Layer 2. The software necessary to 
turn the unreliable broadcasting offered 
by layer 1 into reliable broadcasting 
resides in layer 2. It is normally part of 
the operating system kernel. As a sim¬ 
ple example of a possible (but highly 
inefficient) protocol, a message can be 
reliably broadcast to n machines by hav¬ 
ing the kernel send each machine, in 
turn, a point-to-point message and then 
wait for an acknowledgment. This pro¬ 
tocol takes 2 n messages per reliable 
broadcast. We designed a different pro¬ 
tocol, described below under “Reliable 
broadcasting,” that takes a fraction more 
than two messages on the average, in¬ 
stead of 2 n. 

The main function of layer 2 is to 
ensure reliable broadcasting. Thus, when 
layer 3 hands a message to layer 2 and 
asks that it be reliably broadcast, layer 
3 does not have to worry about how this 
is implemented or what happens if the 
hardware loses a message. Layer 2 takes 
care of it all. 

In addition to being inefficient, the 
protocol that sends a point-to-point 
message to every machine has a more 
serious problem. When two machines, 
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A and B, broadcast simul¬ 
taneously, the results can be 
interleaved. Some machines 
may get the broadcast from 
A before the one from B, 
and other machines may re¬ 
ceive them in the reverse 
order, depending on network 
topology, lost messages, and 
so on. This problem, which 
makes programming diffi¬ 
cult, cannot happen in the 
protocol described below. 

Because its broadcasts are 
globally ordered, all ma¬ 
chines get either A’s broad¬ 
cast followed by B’s or B's 
broadcast followed by A’s. 

The protocol guarantees that 
all user processes get broad¬ 
casts in the same order. 

Layer 3. The third layer, 
the language runtime system, 
is usually a set of library pro¬ 
cedures compiled into the ap¬ 
plication program. Concep¬ 
tually, variables and objects 
can be private or shared. Private objects 
are not visible on other machines, so 
they can be accessed by direct memory 
reads and writes. Shared objects are 
replicated on all machines. Reads to 
them are local, the same as reads to 
private objects. Writes are done by reli¬ 
able broadcasting. Objects are entirely 
passive; they contain only data, not pro¬ 
cesses. 

Layer 4. Although programmers can 
use the distributed shared memory by 
making direct calls on layer 3, it’s much 
more convenient to use the language 
support provided by layer 4. We have 
designed a language, Orca, 7 for parallel 
programming using distributed shared 
objects and have implemented a com¬ 
piler for it. 

In Orca, programmers can declare 
shared objects, each one containing a 
data structure for the object and a set of 
procedures that operate on it. Opera¬ 
tions on shared objects are atomic (in¬ 
divisible as seen from the outside) and 
serializable (they happen in some un¬ 
specified but feasible order). In other 
words, when multiple processes update 
the same object simultaneously, the fi¬ 
nal result is as if the updates were per¬ 
formed sequentially, in some unspeci¬ 
fied order, with each update completed 
before the next one began. 


Layer 

4 

The Orca parallel programming language 

nr 

User 

3 

Object management (language runtime system) 

mode 

t 

2 

Reliable broadcasting (sequencer code) 

A 

Kernel 

1 

Hardware (including network) 

mode 

t 





Figure 3: Structure of the proposed model. 



Figure 4: System structure. Each kernel is capable 
coming the sequencer, but at any instant only one 
functions as sequencer. 


Reliable broadcasting 

The heart of our proposal is the effi¬ 
cient implementation of indivisible, re¬ 
liable broadcasting (layer 2). Once that 
has been achieved, the rest can be built 
on that foundation. This section sum¬ 
marizes the mechanism we used to 
achieve reliable broadcasting (in soft¬ 
ware) over an unreliable network. 
(Readers interested in protocol details 
should consult Kaashoek et al. 8 ) 

Figure 4 shows the hardware/software 
configuration required for reliable 
broadcasting. The “user programs” rep¬ 
resent the application programs and their 
runtime systems (layers 3 and 4). The 
kernel represents layer 2. The network 
is layer 1. The hardware of all the ma¬ 
chines is identical, and they all run ex¬ 
actly the same kernel and application 
software. However, when the applica¬ 
tion starts, one machine is elected as 
sequencer (like a committee electing a 
chairperson). If the sequencer machine 
subsequently crashes, the remaining 
members elect a new sequencer using 
one of the many known algorithms (for 
example, highest network address wins). 
We designed the protocol to withstand 
sequencer crashes. (See Kaashoek and 
Tanenbaum 9 for details on fault toler¬ 
ance.) 


of be- 
of them 


quence of events for achiev¬ 
ing reliable broadcasting can 
be summarized as follows. 

(1) The user traps to the 
kernel, passing it the 
message. 

(2) The kernel accepts the 
message and blocks the 

(3) The kernel sends it to 
the sequencer as a 
point-to-point message. 

(4) The sequencer adds a 
sequence number and 
broadcasts the message. 

(5) When the sending ker¬ 
nel sees the broadcast, 
it unblocks the user. 

The sending kernel also 
starts a retransmission timer 
in case either the message or 
the resulting broadcast is lost. 
A unique ID ensures that the 
sequencer never broadcasts 
the same message twice. 

When the sequencer receives a Re¬ 
quest for Broadcast message, it checks 
the message’s unique ID to see if it is a 
retransmission. If so, the sequencer in¬ 
forms the sender that the message has 
already been transmitted. If not (the 
normal case), the sequencer assigns the 
next sequence number to the message, 
which is then broadcast and stored in a 
history buffer in case it is lost and must 
be retransmitted. 

Let’s consider what happens when a 
kernel receives a broadcast. First, the 
kernel compares the message’s sequence 
number to that of the most recently 
received broadcast. If the new number 
is 1 higher (normal case), no broadcasts 
have been missed, so the message is 
passed up to the application program. 

Now suppose that the newly received 
broadcast has sequence number 25, while 
the previous one had number 23. The 
kernel is immediately alerted to the fact 
that it has missed number 24, so it sends 
a point-to-point message to the sequenc¬ 
er asking for a private retransmission of 
the missing message. The sequencer 
fetches the missing message from its 
history buffer and sends it. When it 
arrives, the receiving kernel processes 
24 and 25, passing them to the applica¬ 
tion program in numerical order. Thus, 
the only effect of a lost message is a 
minor time delay. All application pro- 
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grams see all broadcasts in the same 
order, even if some messages are lost. 
This is the essence of our reliable broad¬ 
cast protocol. 

Now let’s look at the management of 
the history buffer. Unless something is 
done to prevent it, the history buffer 
fills up quickly. However, if the sequenc¬ 
er knows that all machines have cor¬ 
rectly received broadcasts, say, 0 through 
23, it can delete them from its history 
buffer. Piggybacked acknowledgments 
contained in the Request for Broadcast 
messages provide it with this informa¬ 
tion. In addition, each machine period¬ 
ically sends the sequencer this informa¬ 
tion, even if it has nothing to broadcast. 
The sequencer can also request this in¬ 
formation. 

Alternative protocol. In the broad¬ 
cast protocol described above, method 
PB, the user sends a point-to-point 
message to the sequencer, which then 
broadcasts it. In a variant, method BB, 
the user broadcasts the message, in¬ 
cluding a unique identifier. When the 
sequencer sees this, it broadcasts an 
accept message containing the unique 
identifier and its newly assigned se¬ 
quence number. A broadcast is “offi¬ 
cial” only when the Accept message has 
been sent. 

These protocols are logically equiva¬ 
lent, but they have different performance 
characteristics. In method PB, each mes¬ 
sage appears in full on the network twice: 
once to the sequencer and once from 
the sequencer. Thus, a message of length 
m bytes consumes 2m bytes of network 
bandwidth. However, only the second 
of these is broadcast, so each user ma¬ 
chine is only interrupted once (for the 
second message). 

In method BB, the full message ap¬ 
pears only once on the network, so only 
half the bandwidth of method PB is 
consumed. There is also a very short 
Accept message, but this consumes hard¬ 
ly any bandwidth. On the other hand, 
with method BB, every machine is in¬ 
terrupted twice, once for the message 
and once for the Accept. Thus, method 
PB (to sequencer plus broadcast) wastes 
bandwidth to reduce interrupts com¬ 
pared to method BB (user broadcast 
plus Accept broadcast). 

We have implemented both methods 
and are now running experiments com¬ 
paring them. Depending on the results 
of these experiments, we are likely to go 
to a hybrid scheme, using method PB 


for short messages and method BB for 
long ones. 

In summary, this protocol allows reli¬ 
able broadcasting on an unreliable net¬ 
work in just over two messages per reli¬ 
able broadcast. Each broadcast is 
indivisible, and all applications see all 
messages in the same order, no matter 
how many are lost. The worst that can 
happen is a short delay when a message 
is lost, but that rarely happens because 
modern LANs have very low (but not 
zero) error rates. If two processes at¬ 
tempt broadcasting at the same time, 
one will get to the sequencer first and 
win. The other will see a competitor’s 
broadcast coming back from the se¬ 
quencer and, realizing that its request 
has been queued and will appear short¬ 
ly, will simply wait. 

Comparison. Kaashoek et al. 9 have 
compared our scheme with other pub¬ 
lished protocols for reliable broadcast¬ 
ing, so we’ll limit our comparison to just 
a few of the more significant protocols. 

Chang and Maxemchuk 10 describe a 
family of protocols for reliable broad¬ 
casting, of which non-fault tolerance is 
a special case. Their protocol for the 
non-fault tolerant case uses a sequenc¬ 
er, like ours, but they have the nodes 
ordered in a logical ring, with the se¬ 
quencer advancing along the ring with 
every message sent. This motion of the 
sequencer is almost free when the traf¬ 
fic is heavy, but costs an extra message 
per broadcast when it is not. On the 
average, their protocol requires two to 
three messages per reliable broadcast. 
Ours does it in just a fraction over two. 

In addition, their protocol uses more 
storage because the moving sequencer 
requires storing the history buffer on all 
machines. With a 1-megabyte history 
buffer and 100 machines, we need 1 
megabyte of memory for the history 
buffer; they need 100 megabytes. 

Finally, in our method PB, each reli¬ 
able broadcast uses one point-to-point 
message and one broadcast message. 
With n »1 machines, we generate about 
n interrupts per reliable broadcast. In 
their protocol (similar to our method 
BB), all messages are broadcast, so they 
need between 2 n and 3 n interrupts per 
reliable broadcast. When there are hun¬ 
dreds of broadcasts per second, their 
scheme uses much more CPU time than 
ours. 

Another family of fault-tolerant pro¬ 
tocols is the Isis system of Birman and 


Joseph. 11 They use a distributed two- 
phase commit protocol to achieve glo¬ 
bal ordering, something we achieve in 
two messages per broadcast. Realizing 
that their protocol is inefficient, they 
propose alternative protocols with weak¬ 
er semantics. Our method shows that it 
is not necessary to weaken and compli¬ 
cate the semantics to achieve efficiency. 
Isis, however, does provide a high de¬ 
gree of fault tolerance, which our basic 
protocol does not. Although not dis¬ 
cussed in this article, our protocol can 
provide fault tolerance if desired. 9 Fur¬ 
thermore, Isis supports simultaneous 
use of overlapping process groups. Our 
groups are disjoint, with each applica¬ 
tion forming its own group and no pro¬ 
vision for global ordering between ap¬ 
plications. 

A few researchers have proposed pro¬ 
viding broadcasting as an operating sys¬ 
tem service, as we do. In this category, 
for example, is the V system of Cheriton 
and Zwaenepoel, 12 which supports 
broadcasting but does not guarantee 
reliability. It has the problem of making 
the programmer’s job more difficult 
compared to a system that guarantees 
reliable broadcasting. 

Object management 

On top of the broadcast layer is a 
layer that manages shared objects, im¬ 
plemented by a package of library pro¬ 
cedures (in user space). Our design is 
based on the explicit assumption that 
shared objects are read much more of¬ 
ten than they are written. Our initial 
measurements of some parallel applica¬ 
tions (for example, the traveling sales¬ 
man problem) show that ratios of 10:1 
or even 100:1 are not unusual. There¬ 
fore, we have chosen to replicate each 
object on all machines that use the ob¬ 
ject. (Note that multiple, independent 
applications may be running at the same 
time, so not every machine needs every 
object.) All replicas have equal status: 
There is no concept of a primary object 
and secondary copies. 

Two operations are defined on ob¬ 
jects: Read and Write. Reads are done 
on the local copy, without any network 
traffic. A Read on a shared object is 
only slightly more expensive thanaRead 
on a Private object (due to some lock¬ 
ing). A Write to a shared object can be 
done by reliably broadcasting either its 
new value or an operation code and 


14 


COMPUTER 








parameters to let each machine recom¬ 
pute the new value. The former strategy 
is attractive for small objects; the latter 
one for large objects. It is up to the 
runtime system to pick the strategy. Since 
all machines process all broadcasts in 
the same order, when equilibrium is 
reached, all copies will settle down to 
the same value. 

This scheme does not provide com¬ 
plete memory coherence because if 
machine A initiates a reliable broadcast 
to update a shared object, and machine 
B reads the (local copy of the) object a 
nanosecond later, B will get the old 
value. On the other hand, it does pro¬ 
vide for atomic update and serializabil- 
ity (managed by the runtime system). 
This is almost as good. For example, 
consider a multiprocessor with a true 
shared memory. At a certain moment, 
process A wants to write a word, and 
process B wants to read it. Since the two 
operations may take place a microsec¬ 
ond apart, the value read by B depends 
on who went first. Despite memory co¬ 
herence, the value read by B is deter¬ 
mined by the detailed timing. Our shared 
object model has a similar property. In 
both cases, programs whose correct func¬ 
tioning depends on who wins the race to 
memory are living dangerously (al¬ 
though the window is larger in our mod¬ 
el than with a multiprocessor — milli¬ 
seconds instead of microseconds). Thus, 
although our memory model does not 
exhibit true coherence, in reality, seri- 
alizability plus total global message or¬ 
dering are sufficient properties. And 
we do have those. 

Much research on distributed shared 
memory is based on the work of Li and 
Hudak. 2 Their method moves fixed-size 
pages around the network in point-to- 
point messages. The method is frequent¬ 
ly inefficient because many data struc¬ 
tures are smaller than a page. The rest 
of the page is not needed, but it must be 
copied anyway. 

In addition, if two unrelated, shared 
data structures accidentally reside on 
the same page (false sharing), competi¬ 
tion for this page may cause it to thrash 
back and forth. The larger the page size, 
the worse the problem. Furthermore, 
accesses to a shared data structure may 
require multiple machine instructions. 
Pages are not automatically locked while 
an object is being accessed (because the 
paging system does not know when ac¬ 
cess to a software object begins and 
ends). Consequently, a page may have 


Performance of reliable broadcasting 


We have modified the Amoeba 
kernel 12 to support our reliable 
broadcast protocol. The modified 
kernel runs on a collection of 16- 
MHz Motorola 68030 processors 
connected by a 10-Mbps Ethernet. 

We have run various experiments 
on this system to measure its per¬ 
formance. In the first experiment, 
one process continuously broad¬ 
casts null messages as fast as it 
can to measure the maximum 
broadcast rate by a single process. 

This tests the worst possible case: 

Since all machines but one are si¬ 
lent, they are not sending piggy¬ 
backed acknowledgments back to 
the sequencer. Without these ac¬ 
knowledgments, the sequencer 
must send out a Request for Status every 64 messages. In this experiment, we 
achieved 370 reliable broadcasts per second with up to 16 processors. 

Even though we are measuring broadcasting, the performance is better than 
most RPC (point-to-point) systems, partly because our protocol requires only two 
messages per broadcast, whereas RPCs often require three, the last being an 
acknowledgment. (As an aside, these results differ from our earlier results be¬ 
cause we have now designed and implemented a new kernel that can handle 
broadcasting over an arbitrary internetwork consisting of LANs and buses. This 
scheme also supports automatic network reconfiguration and management. 
These changes entirely account for differences between the results here and 
those published previously.) 

The second experiment consists of having not one, but multiple processes 
broadcasting at the same time, to see what the effect of contention is. In this ex¬ 
periment, we varied the number of senders from 2 to 14, with the receiving group 
equal to the number of senders. The figure shows the results. 

Multiple senders get a higher throughput than just one because if two ma¬ 
chines send messages to the sequencer almost simultaneously, the first one to 
arrive will be broadcast first, but the second one will be buffered and broadcast 
immediately afterwards. This simple form of pipelining increases the parallelism 
of the system, and thus increases the broadcast rate. As the number of senders 
increases, performance drops slightly due to contention for the Ethernet. We 
were unable to make consistent measurements for 15 and 16 processors due to 
technical limitations of our equipment. 

A word about scaling is appropriate here. It has been pointed out to us that the 
sequencer will become a bottleneck in very large systems. While this is true, few 
current systems or applications suffer from this limit. With our system (2-MIPS 
CPUs and 10-Mbps Ethernet), we can support on the order of 800 reliable broad¬ 
casts per second, as shown above. Since broadcast messages are usually short, 
there is bandwidth to spare. For many problems, the read-to-write ratio is quite 
high. Suppose (conservatively) that 90 percent of the operations are reads and 
10 percent are writes. Then we can support 8,000 operations per second on 
shared objects (7,200 reads, done locally, and 800 writes, done by broadcast¬ 
ing). We know of very few applications that would be hindered by a limitation of 
8,000 operations per second on shared objects. Furthermore, with 20-MI PS 
RISC processors and 100-Mbps fiber optic networks, we extrapolate this limit to 
about 80,000 operations per second on shared objects before the sequencer be¬ 
comes the bottleneck. 
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to be accessed several times to com¬ 
plete a single logical operation on a data 
structure. With an object-based system 
this cannot happen. 

To get around the inefficiency of dis¬ 
tributed shared memory using fixed- 
size pages, some researchers have pro¬ 
posed using objects, as we have. 
However, lacking our reliable broad¬ 
casting, they have needed other meth¬ 
ods to gain performance. A common 
approach has emphasized weakening 
the semantics of what shared memory 
means. For example, suppose A, B , and 
C all update the same word in quick 
succession, followed by a read by D. 
Inspired by the work of the Dash sys¬ 
tem 3 on multiprocessor caches, the 
Munin system 4 allows D to get any of 
the three values written. This optimiza¬ 
tion allows writes to be postponed until 
a read is done. Munin also allows pro¬ 
grammers to declare different seman¬ 
tics for different shared objects to per¬ 
form other optimizations. We believe 
that our model offers a simpler and 
cleaner semantic model, is easier for 
programmers to use, and provides good 
performance (see sidebars). 

Orca 

Orca is a procedural language whose 
sequential constructs are roughly simi¬ 
lar to languages like C or Modula 2 but 
which also supports parallel processes 
and shared objects. 

Guiding principles. The four guiding 
principles behind the Orca design are 
transparency, semantic simplicity, seri- 
alizability, and efficiency. 

Transparency. By transparency, we 
mean that programs (and programmers) 
should not be aware of where objects 
reside. Location management should be 
fully automatic, and the programmer 
should not even be aware of whether 
the program is running on a machine 
with physical shared memory or on one 
with disjoint memories. Ideally, the same 
program should run on both types of 
machines; however, nearly all parallel 
programming languages are aimed at 
one or the other, not both. (Of course, 
one can always simulate message pass¬ 
ing on a multiprocessor, but this is far 
from optimal.) 

Semantic simplicity. Programmers 
should be able to form a simple mental 


model of how the shared memory works. 
This principle rules'out incoherent mem¬ 
ory, in which reads to shared data some¬ 
times return good values and sometimes 
stale (incorrect) ones. 

Serializability. In a parallel system, 
many events happen simultaneously. By 
making operations serializable, we guar¬ 
antee that operations on objects are 
indivisible (atomic) and that the ob¬ 
served behavior is the same as in some 
sequential execution. Operations on 
objects are guaranteed not to be inter¬ 
leaved, which contributes to semantic 
simplicity, as does the fact that all ma¬ 
chines are guaranteed to see exactly the 
same sequence of serial events. Thus, 


the programmer’s model is that the sys¬ 
tem supports operations. These opera¬ 
tions may be invoked at any moment, 
but if any invocation would conflict with 
an operation currently taking place, the 
second operation will not begin until 
the first one has completed. In other 
words, the system has the responsibility 
for making sure that parallel activities 
do not interfere with one another. 

Efficiency. Since we are proposing a 
system for solving real problems, effi¬ 
ciency is also important. 

Principal concepts. Parallelism in Orca 
is based on two orthogonal concepts: 
processes and objects. 


Parallel applications in Orca 


Orca is a procedural, type-secure language intended for implementing parallel 
applications on distributed systems. 1-3 Below, we briefly discuss four examples of 
problems it has been used for and give their measured speedups on the broadcast 
system. 

Matrix multiplication (MM) is an example employing “trivial parallelism.” Each pro¬ 
cessor is assigned a fixed portion of the result matrix. Once the work-to-do has been 
distributed, all processors can proceed independently from each other. The speedup 
is not perfect because it takes some time to initialize the source matrices (of size 250 
x 250) and the portions are fixed but not necessarily equal if the matrix size is not di¬ 
visible by the number of processors. 

The Traveling Salesman Problem (TSP) is discussed in detail in the paper. Its main 
characteristic is the shared variable containing the current best solution. This variable 
is stored in a shared object that is read very frequently. If a new better route is found, 
all copies of the object are updated immediately, using the efficient broadcast proto¬ 
col. It is important that the updating takes place immediately, lest some processors 
continue to use an inferior bound, reducing the effectiveness of the pruning. TSP 
achieves a speedup close to linear. 

In the all-pairs shortest paths (ASP) problem, communication overhead is much 
higher. ASP uses an iterative algorithm. Before each iteration, some process selects 
one row of the distances matrix as the pivot row and sends it to all other processes. If 
implemented with point-to-point messages, the communication overhead would be lin¬ 
ear with the number of processors. With our multicast protocol, however, the over¬ 
head is reduced to a few messages, resulting in high speedups. 

Of course, not all parallel applications benefit from broadcasting. In successive 
overrelaxation (SOR), each processor mainly communicates with its neighbors. SOR 
is a worst-case example for our system, because point-to-point messages between 
neighboring nodes are implemented as broadcast messages received by all nodes. 
Still, the program achieves a reasonable speedup. 
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Processes. Processes are active enti¬ 
ties that execute programs. They can be 
created and destroyed dynamically. It is 
possible to read in an integer n, then 
execute a loop n times, creating a new 
process on each iteration. Thus, the 
number of processes is not fixed at com¬ 
pile time; it is determined during execu¬ 
tion. 

The Orca construct for creating a new 
process is the 

fork func(param,...) 

statement, which creates a new process 
running the procedure Func with the 
specified parameters. The user may spec¬ 
ify a processor or use the standard de¬ 


fault of running it on the current proces¬ 
sor. Objects may be passed as parame¬ 
ters (call by reference). A process may 
fork many times, passing the same ob¬ 
jects to each of the children. This is how 
objects come to be shared among a col¬ 
lection of processes. There are no glo¬ 
bal objects in Orca. 

Objects. In Orca, objects are passive. 
They do not contain processes or other 
active elements. Each object contains 
some data structures, along with defini¬ 
tions of one or more operations that use 
the data structures. The operations are 
defined by Orca procedures written by 
the programmer. An object has a spec¬ 
ification part and an implementation 


part, similar to Ada packages or Modu- 
la 2 modules. Technically, Orca is ob¬ 
ject based, not object oriented, in that it 
supports encapsulated abstract data 
types, but without inheritance. 

A common way of programming in 
Orca is the Replicated Worker Para¬ 
digm. 5 In this model, the main program 
starts out by creating a large number of 
identical worker processes, each with 
the same objects as parameters, so they 
are shared among all the workers. Once 
the initialization phase is completed, 
the system consists of the main process, 
along with some number of identical 
worker processes, all of which share 
some objects. Processes can perform 
operations on any of their objects when¬ 
ever they want to, without considering 
the mechanics of how many copies are 
stored or where, how updates take place, 
which synchronization technique is used, 
and so on. As far as the programmer is 
concerned, all objects are effectively 
located somewhere in one big shared 
memory and protected by a monitor 
that prevents simultaneous multiple 
updates. 

Simple example. As a simple exam¬ 
ple of an object specification, consider a 
simple object consisting of an integer 
variable with two operations on it: Read 
and Write. If this object is subsequently 
shared among multiple processes, any 
of them can read or write the value of 
the integer. 

The Orca specification part looks like 
this: 

object specification Sharedlnt; 
operation read():integer; 
operation write(val:integer); 

end; 

The implementation part looks like 
this: 

object implementation Sharedlnt; 
n: integer; # the value 

operation read():integer; 
begin 
return n; 
end; 

operation write(val:integer); 
begin 
n := val; 
end; 

end; 



Measured performance for four Orca programs: (a) Matrix multiplication, using 
input matrices of size 250 x 250, (b) traveling salesman problem, averaged over 
three randomly generated graphs with 12 cities each, (c) all-pairs shortest 
paths problem, using an input graph with 300 nodes, and (d) successive over¬ 
relaxation, using a grid with 80 columns and 242 rows. Each graph shows the 
speedup of the parallel Orca program on n CPUs over the same program run¬ 
ning on one CPU. 
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Figure 5: Model of TSP program using replicated worker paradigm. 


To declare and use an object of type 
Sharedlnt, the programmer might write 

s: Sharedlnt; 

i: integer; # ordinary integer 

s$write(100); # set object to 100 

i := s$read(); # set i to 100 

Although the programming style sug¬ 
gested by this trivial example is suffi¬ 
cient for some programs, many others 
require some kind of synchronization 
method. A common example is barrier 
synchronization, in which n workers are 
busy computing something, and the next 
step can begin only when all of them 
finish. 

Synchronization in Orca is handled 
with guarded commands, in which an 
operation consists of a number of (guard, 
statement) pairs. Each guard is a side- 
effect-free Boolean expression, and each 
statement is an arbitrary piece of se¬ 
quential Orca code. When the opera¬ 
tion is invoked, the language runtime 
system evaluates the guards one at a 
time (in an unspecified order) and, as 
soon as it finds one that is true, executes 
the corresponding statement. For ex¬ 
ample, to implement barrier synchroni¬ 
zation, the main process could create a 
shared object with operations that ini¬ 
tialize it, increment it, and synchronize 
on it (that is, wait until it reaches n ). The 
main process would initialize it to 0, 
then fork off all the workers. When 
each worker finished its work, it would 
invoke the Increment operation and then 
the Synchronize operation. The latter 
would block the calling process until 
the value reached n, at which point all 
the processes would be released to start 
the next phase. 

It is essential that the synchroniza¬ 
tion operation be programmed as a sin¬ 
gle Orca operation (although this oper¬ 
ation may contain arbitrarily many Orca 
statements). Having an operation to 
merely return the value, and then mak¬ 


ing a decision on it in open code, loses 
the crucial atomicity property. 

Traveling salesman problem. As a 

slightly more elaborate example, con¬ 
sider an Orca implementation of the 
traveling salesman problem. In the TSP, 
the computer is given a starting city and 
a list of cities to visit. It has to find the 
shortest path that visits each city exact¬ 
ly once and returns to the starting city. 

The usual algorithm for solving TSP 
is branch and bound. Suppose the start¬ 
ing city is New York, and the cities to be 
visited are London, Sydney, Tokyo, 
Nairobi, and Rio de Janeiro. The main 
program starts out by computing some 
possible path (for example, using the 
closest-city-next algorithm) and deter¬ 
mining its length. Then it initializes a 
soon-to-be-shared object, BestPath, 
containing this path and its length. As 
the program executes, this object will 
always contain the best path found so 
far and its length. Next it forks off some 
number of workers, each getting the 
shared object as a parameter, as shown 
in Figure 5. 

Each worker is given a different par¬ 
tial path to investigate. The first one 
tries paths beginning New York-Lon- 
don, the second New York-Sydney, the 
third New York-Tokyo, and so on. Very 
roughly, the algorithm used by a worker 
given a partial path plus k cities is to 
first check if the length of the partial 
path is longer than the best complete 
path found so far. If so, the process 
terminates itself. If the partial path is 
still a potential candidate, the process 
generates k new partial paths for inves¬ 
tigation, one per city in the list, and 
forks these off to k new workers. 

To avoid forking off too many pro¬ 
cesses, when the list of remaining cities 
is less than n, the process tries all the 
possible combinations itself. Other op¬ 
timizations are also used. Whenever a 
new best path is found, an update oper¬ 
ation executed on the shared object 


BestPath replaces the previous best path 
by the new one. When the Orca compil¬ 
er detects an assignment to a variable in 
a shared object, it generates code caus¬ 
ing the runtime system to issue a reli¬ 
able broadcast of the new value. In this 
manner, all the details of managing 
shared objects are hidden from the pro¬ 
grammer. 

A moment’s thought will show that 
reads of BestPath will occur very often, 
while writes will occur hardly at all, 
certainly not after the program has been 
running for a while and has found a path 
close to the optimal one. Remember 
that reads are done entirely locally on 
each machine, whereas writes require a 
reliable broadcast. The net result is that 
the vast majority of operations on the 
shared object do not require network 
traffic, and the few that do take only 
two messages. Consequently, the solu¬ 
tion is highly efficient. We have achieved 
almost linear speedup on some applica¬ 
tions, as shown in the sidebar on Orca 
applications. 

Comparison. It is instructive to brief¬ 
ly compare Orca with some alternative 
approaches to parallel programming. 
There are many languages based on 
message passing, which is of a concep¬ 
tually lower level than shared objects. 
Languages that support shared memory 
typically use semaphores or monitors to 
protect critical regions. Both of these 
work adequately on small shared-mem¬ 
ory machines but poorly on large dis¬ 
tributed systems because of their inher¬ 
ently centralized locking scheme. 

The Emerald system 6 is somewhat sim¬ 
ilar to Orca. Like Orca, it supports shared 
objects, but, unlike Orca, it does not 
replicate objects. This means that when 
a caller on machine 1 invokes an opera¬ 
tion on an object located on machine 2 
using a parameter on machine 3, mes¬ 
sages must be sent to collect all the 
necessary information in the same place. 
Since there is no automatic migration, 
execution will be inefficient unless the 
programmer arranges colocation for 
things that go together. 

Alternatively, for efficiency on each 
call, the programmer can specify that 
parameter objects be sent to the ma¬ 
chine where the object resides and re¬ 
main there after the invocation. The 
programmer can also specify whether 
the result is to remain there or not. In a 
truly transparent system these issues 
would not arise. 


COMPUTER 



















In Orca, the runtime system decides 
whether or not it wants to replicate 
objects and where. Using the broadcast 
system described above, all objects are 
replicated on machines that need them 
(but other Orca implementations do it 
differently). In any event, it is not the 
programmer’s responsibility. Object 
management is handled automatically, 
and the system decides whether to per¬ 
form operations locally or remotely. The 
Orca approach comes much closer to 
providing the semantics of a shared- 
memory multiprocessor. 

Yet another shared object scheme is 
Linda. s Linda supports the concept of a 
shared tuple space that is equally acces¬ 
sible to processes on all machines. Lin¬ 
da is fully location transparent, but the 
primitives inserting and deleting tuples 
are low level. In contrast, Orca’s opera¬ 
tions on shared objects can be simple or 
complex, as the programmer wishes. 

I n conclusion, our model combines 
the best properties of both multi¬ 
processor and multicomputer sys¬ 
tems: easy-to-build hardware and a con¬ 
ceptually simple programming model. 
The programmer defines and invokes 
operations on shared objects, the run¬ 
time system handles reads and writes on 
these objects, and the reliable broad¬ 
cast layer implements indivisible up¬ 
dates to objects using the sequency pro¬ 
tocol. The resulting system is easy to 
program, easy to build, and has accept¬ 
able performance on problems with a 
moderate grain size in which reads are 
much more common than writes. 

Our conclusion is that using reliable 
broadcasting to support replicated, 
shared objects is a good approach to 
parallel programming. It is simple to 
understand and efficient to implement. 
We believe that this paradigm offers a 
new and effective way to exploit paral¬ 
lelism in future computing systems. ■ 
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Model-Based Visual 
Feedback Control for a 
Hand-Eye Coordinated 
Robotic System 


John T. Feddema, Sandia National Laboratories 

C.S. George Lee, Purdue University 

O. Robert Mitchell, University of Texas at Arlington 


Using models and 
differential, as 
opposed to absolute, 
visual feedback, this 
flexible robot control 
system tracks a moving 
object and guides the 
robot gripper to it. 


S ensor integration is vital in flexible manufacturing workcells. Without 
sensors, manufacturing systems must control environments precisely and 
maintain exact knowledge of plant models. A change in a task or the 
environment involves the time and expense of adjusting and recalibrating the 
system. With appropriate sensors, the system becomes flexible enough to compen¬ 
sate for such changes automatically. The reductions both in downtime for mis¬ 
aligned parts and in fixturing costs more than offset initial sensor costs. 

Sensors allow robots to go beyond simple pick-and-place operations, enabling 
them to manipulate parts with uncertain characteristics and locations. Sensors for 
vision, force, range, and touch can eliminate the need to position parts exactly, thus 
minimizing workpiece fixturing. They can also verify assembly and gauge parts on 
line, thus eliminating the need for off-line inspection. 

Vision sensors are especially helpful, and many industry systems currently use 
single-camera systems to locate parts. However, these systems are typically slow 
and inaccurate. In their normal mode of operation, they take a picture, analyze the 
image, extract position information from it, and move the robot accordingly. If the 
part moves unpredictably while the image is being analyzed, the robot will not 
“know” its new position. 

To track randomly moving parts, a robot must have real-time vision feedback. 
This feedback, often called vision-guided servoing, gives the robot control system 
appropriate signals for mating the end-effector, or robot gripper, with the part. 

There are many potential applications for this technology. These include preci¬ 
sion part placement, arc welding, seam tracking, vehicle guidance, space structure 
control, and composite layout. However, implementation of vision-guided servo¬ 
ing requires solutions to several challenging problems. For example, effective 
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Figure 1. Coordinate frames in robot’s workspace. The equations are used to de¬ 
termine the position of a feature point in the image planes for cameras A and B. 


robot control implies a 10- to 100-milli¬ 
second vision cycle time (that is, the 
time required to analyze images and 
extract features from them). Providing 
this operational bandwidth with cur¬ 
rent off-the-shelf image processing 
equipment is difficult and requires sig¬ 
nificant reductions in the amount of 
image data. One way we can reduce 
data is to search small region-of-inter- 
est windows for a few salient image 
features. But how many and which fea¬ 
tures should we choose to control the 
robot’s desired degrees of freedom. 

Another problem is the variation in 
vision cycle time with image complexi¬ 
ty and size. This requires the system’s 
control structure to accommodate non- 
uniform sampling of the vision feed¬ 
back. The resulting variable delay makes 
discrete time analysis and control ex¬ 
tremely difficult, if not impossible. We 
need another means of control. 

This article focuses on the integra¬ 


tion of a single camera into a robotic 
system to control the relative position 
and orientation (that is, the pose) be¬ 
tween the robot’s end-effector and a 
moving part in real time. We consider 
only monocular vision techniques, as 
opposed to binocular (or stereo) vision 
techniques, because of current limita¬ 
tions in the speed of computer vision 
analysis. Our approach uses geomet¬ 
ric models of both the part and the 
camera, as well as the extracted image 
features, to generate the appropriate 
robot control signals for tracking. We 
also use part and camera models dur¬ 
ing the teaching stage to predict impor¬ 
tant image features that will appear 
during task completion. 

Problem statement 

Spatial relationships play an impor¬ 
tant role in robotics. The relative pose 


between a robot’s end-effector and a 
workpiece tells us how close the robot is 
to contact with the workpiece (usually 
an eventual subgoal of a task). As hu¬ 
man beings, we use the sense of sight to 
estimate the relative pose of objects 
with respect to our hands. Similarly, we 
would like to use computer vision to 
estimate the relative pose of the robot’s 
gripper to a workpiece. The estimated 
pose could then be fed back into the 
robot controller where control adjust¬ 
ments could be made in the gripper’s 
pose. 

Correct camera placement is critical 
to hand-eye coordinated robotic mo¬ 
tion. Human beings, for instance, posi¬ 
tion their heads closer to the object for 
a task such as threading a needle than 
they do for tightening a large bolt. Sim¬ 
ilarly, the appropriate camera position 
relative to the robot’s workspace de¬ 
pends on the precision of the task and 
the resolution of the camera. We will 
consider the camera in two positions: 
on the robot end-effector (camera A in 
Figure 1) or stationary with respect to 
the base coordinate frame of the robot 
(camera B in Figure 1). 

To analyze the visual feedback prob¬ 
lem, we must first look at the spatial 
relationships among four objects in Fig¬ 
ure 1: 

• the robot’s gripper, 

• the robot’s camera, 

• the stationary camera, and 

• a workpiece. 

The position and orientation between 
the robot’s end-effector, the cameras, 
and the part may be represented by 4 x 
4 homogeneous transformations. 1 For 
example, the pose relationship of a work- 
piece w with respect to a fixed coordi¬ 
nate frame 0 is given by 



where n R w is an orthonormal 3x3 rota¬ 
tion matrix, 0 is a 3 x 1 row vector of 
zeros, and °p w is a 3 x 1 position vector. 
The multiplication property of homo¬ 
geneous transformations allows the pose 
of the workpiece with respect to the 
fixed frame 0 to also be expressed as a 
product of the homogeneous transform 
of the robot’s end-effector with respect 
to the frame 0, °T e , and the homoge¬ 
neous transform of the workpiece with 
respect to the robot’s end-effector, e T w : 
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°T W = °T e e T w 

This property may also be used to 
describe the pose of the workpiece’s 
features, f„ / = 1 ,..., m, with respect to 
the frame 0: 

°T f . = °T W w T f . for i = \, ... ,m 

These features might include holes, edg¬ 
es, or corners on the workpiece. Ideally, 
the transformations of the features with 
respect to the workpiece, W T, , could be 
determined from a CAD model of the 
workpiece. 

While homogeneous transformations 
correctly describe the relative pose in 
the Cartesian space between two ob¬ 
jects, they do not describe the camera 
transformation from the three-dimen¬ 
sional Cartesian space into the two-di¬ 
mensional image plane. Geometric op¬ 
tics are often used to model the mapping 
between a point in the Cartesian space 
and a point in the image plane. This 
mapping consists of two stages: a thin 
lens model of the perspective transfor¬ 
mation, r F c and a mapping into a two- 
dimensional plane caused by image sam¬ 
pling, 'S r . For a lens perpendicular to 
the image plane, the transformation from 
the camera frame c to the image plane I 
can be written as 

'f 0 0 ol 

0 f 0 0 [ C P;1 

0 0 0 f |_ 1 J 

0 0 -1 f 


w 'p, = I S r r F c c p,. 


where 'p, is a 2 x 1 vector representing 
the (x, y) position of the point in the 
image plane, w is a scalar scaling factor, 
a x and a y are the camera sampling fac¬ 
tors in pixels per millimeter, ('x 0 , *y 0 ) is 
the focal center in pixels, / is the focal 
length of the camera in millimeters, and 
c p ; is a 3 x 1 vector representing the (x, 
y,z) position of the point with respect to 
the camera frame. Tsia 2 presents more 
complex expressions for 'S r and r F c to 
account for the effects of blurring, lens 
distortion, and quantization. 

Homogeneous transformations and 
the camera model make it possible to 
simulate the positions of the workpiece’s 
features in the image plane of both cam¬ 
eras A and B. Figure 1 shows how to 
determine the ( x , y) position of a fea¬ 
ture point i in both cameras’ image co¬ 
ordinates, given the model of the work- 
piece ( w Pi), its pose with respect to a 
fixed frame 0 ( ( ’T W ), camera A’s pose 
with respect to the robot’s end-effector 
( e T ca ), camera B’s pose with respect to 
the fixed frame 0 (°T cb ), the end-effec¬ 
tor’s pose with respect to the fixed frame 
0 (°T e ), and camera parameters ( Ia S ra , 
ra F ca , Ib S rb , and rb F cb ). 

Computer graphics use these types 
of equations extensively to display 
three-dimensional objects on a two-di¬ 
mensional screen. However, for visual 
feedback control, we are interested in 
an inverse solution. That is, given the 
two-dimensional image positions of the 
workpiece’s features, the model of the 
workpiece, the camera parameters, the 
pose of the robot’s end-effector, and 
the pose of the cameras, what is the 
workpiece’s pose with respect to the 
fixed frame 0? 


Absolute visual 
feedback 

Computer vision has been used with 
robotic systems for quite some time. 
Early robot manufacturers did not 
offer an integrated vision system, so 
vision systems were usually loosely 
coupled into the robotic system as 
after-market add-ons. The long image 
processing time of these systems limit¬ 
ed their use to locating stationary ob¬ 
jects or parts moving at a fixed rate on a 
conveyor. 

Figure 2 shows the position-based, 
look-and-move control structure used 
in most of these systems. 3 Typically, the 
vision system would take several sec¬ 
onds to locate a workpiece, after which 
it would send the robot control system 
the estimated pose of the workpiece 
with respect to a fixed coordinate frame. 
After the robot moved to the appropri¬ 
ate position, the vision system would 
take another “picture” and repeat the 
process. 

Not only were the early vision sys¬ 
tems slow, but they were also very lim¬ 
ited in application. Even today, most 
monocular vision systems will only lo¬ 
cate an object if it is on a plane perpen¬ 
dicular to the camera’s focal axis at a 
fixed distance from the camera. The 
main reason for this is that the camera 
transformation reduces three-dimen¬ 
sional data to two-dimensional data. An 
exact inverse of this equation does not 
exist. Given the (x, y) image position of 
a single point, it is impossible to deter¬ 
mine the (x, y , z) position of the point in 
the 3D space. We can only determine 
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the ray extending from the focal center 
on which the point lies. Fortunately, we 
can determine an object’s pose from 
three or more image points if we know 
the spatial distances between these 
points (see the sidebar “Location deter¬ 
mination problem”). 

We would usually like the robot’s 
end-effector to move to a point relative 
to the workpiece. Suppose this transfor¬ 
mation is given by w T e . Assuming that 
we are using camera B, we will use the 
location-determination method dis¬ 
cussed in the sidebar to denote the mea¬ 
sured object’s pose by the homogeneous 


transformation cb T w .,Then we determine 
the transformation of this desired end- 
effector pose with respect to the robot’s 
base coordinates by premultiplying cb T w 
by °T cb and postmultiplying by w T e . Most 
robot systems will accept this resultant 
homogeneous transformation as an ac¬ 
ceptable command pose. 

The same process could be performed 
with feature points with respect to cam¬ 
era A except the transformation °T ca 
will depend on the robot’s current pose, 
°T e , and the camera’s pose, e T ca . Most 
robotic systems will accept robot move 
statements in terms of homogeneous 


transformations with respect to the ro¬ 
bot’s end-effector. In these cases, we 
need only premultiply by e T ca . The ro¬ 
bot system will take care of the °T e term. 

We can see that it is possible to deter¬ 
mine an object’s pose with respect to a 
camera from extracted and modeled 
feature data of the object. Unfortunate¬ 
ly, this method can lead to absolute 
positioning errors if the camera’s model 
is inaccurate. In addition, because of 
the nonlinear search involved, this loca¬ 
tion determination method proves too 
slow for real-time visual feedback with 
our current computing facilities. 


Location-determination problem 

Fischler and Bolles 1 were among the first to solve the loca¬ 
tion-determination problem. The solution is often used in car¬ 
tography to determine the point in space from which a picture 
was taken based on a set of known landmarks in the image. 

For example, assume that we know the distance between 
several points ( w p,, *p 2 , w p 3 ), as shown in Figure A. Using the 
known squared distance between two points and the cam¬ 
era’s intrinsic parameters, we can write the squared-distance 
equation in quadratic form as a function of the z distances of 
the two points with respect to the camera’s frame. Physically, 
this means that we can move a fixed segment along the two 
rays of these observed points and the z distances of the seg¬ 
ment’s end points will fit a quadratic curve. 

If a third point — noncollinear to the first two — is also ob¬ 
served in image coordinates, we can form two more quadratic 



distance equations. In terms of the z distances of these three 
points with respect to the camera’s frame, these equations 
form three perpendicular quadric surfaces. The places where 
all three surfaces intersect are the simultaneous solutions to 
the three quadratic equations. 

As many as eight possible solutions can exist for a given 
set of three points. However, we are only considering z to be 
positive, which reduces the possible solutions to four. For two 
or more solutions, we must use additional points to narrow 
the solution to one. In practice, a least-squares gradient 
search with several points is often used to compensate for 
modeling errors and the coarse resolution of the pixel mea¬ 
surements. 

Once the (x, y, z) position of three noncollinear points is 
known, we can determine the pose of the workpiece with the 
help of a geometric model. Suppose we have used this loca¬ 
tion-determination method to determine the position of three 
noncollinear points with respect to camera B, ( ob p,, ob p 2 , cb p 3 ), 
using the geometric model data of these same points with re¬ 
spect to the workpiece, ( w p,, w p 2 , »p 3 ), we can determine the 
workpiece’s pose with respect to the camera as follows: 

for k = c,w: 


| k P 2 - k P 1 || 


(*P 2 -* P1 )X(*P3-*P,) 

||( k P 2 - k p 1 )x( k P3- k p,)|| 


where n, o, and a are 3 x 1 vectors that make up rotation ma¬ 
trix R. Then the homogenous transformation of the workpiece 
with respect to the camera is °T W = 0 T 1 (*T 1 )~ 1 . 


Reference 


1. M.A. Fischler and R.C. Bolles, “Random Sample Consensus: A 
Paradigm for Model Fitting with Applications to Image Analysis 
and Automated Cartography,” Comm. ACM, Vol. 24, No. 6, June 
1981, pp. 381-395. 


Figure A. Location determination of workpiece pose 
given the distances between feature points in 3D 
and the position of the points in the image plane. 


24 


COMPUTER 






























Figure 3. Resolved motion rate control structure for visual feedback. 


Differential visual 
feedback 

Differential feedback schemes in ro¬ 
botics date back to the resolved-mo¬ 
tion-rate control structure. 4 A precom¬ 
puted inverse Jacobian matrix is used to 
transform changes in the task space into 
changes in robot joint angles. It has 
been shown that asymptotic stability 
and zero steady-state error can be 
achieved when this Jacobian transfor¬ 
mation is incorporated into a propor¬ 
tional-integral-derivative control loop 
— even when the control model con¬ 
tains errors. 5 This is important for visu¬ 
al feedback since it is often difficult to 
accurately calibrate the camera’s intrin¬ 
sic parameters. 

With this in mind, Weiss et al. 6 de¬ 
scribe an adaptive differential control 
structure that transforms changes in 
image features to changes in robot joint 
angles. They use a model reference adap¬ 
tive controller to compute the control 
input, which makes the output follow a 
reference model. Although the system 
output converges asymptotically to the 
desired value, there may be large initial 
errors in the estimated system parame¬ 
ters, which will cause a large initial er¬ 
ror in the desired output. Such errors 
can greatly increase the searching time 
in the feature extraction process. 

To minimize these initial errors, we 
believe that the Jacobian transforma¬ 
tion from image features to robot joint 


angles should be precomputed from the 
camera and robot models. In this sec¬ 
tion, we look at the resolved-motion- 
rate control structure for differential 
visual feedback and the Jacobian trans¬ 
formations necessary for this control. 

As shown in Figure 3, our resolved 
motion rate control structure for visual 
feedback consists of five components: 

• an off-line feature selector, 

• an image feature extractor, 

• an image feature-based trajectory 
generator, 

• the Jacobian transformation from 
image features to robot joint angles, 
and 

• a lower level robot joint controller. 

We describe these components in re¬ 
verse order to reflect the system hierar¬ 
chy. 

Lower level robot joint controller. 

This component provides for stable ro¬ 
bot motion with a sampling period sig¬ 
nificantly shorter than the vision sam¬ 
pling period. For the system developed 
in our laboratory at Purdue University, 
this lowest level of control was a set of 
six independent joint controllers with 
constant proportional and derivative 
gains set to critically damp the robot’s 
joint motion throughout the workspace. 
Every 0.875 milliseconds, these control¬ 
lers sampled the robot’s joint angles 
and velocities (from encoder values) 
and provided a new control value. The 


desired joint positions were received 
from the outer visual feedback control 
loop every 28 milliseconds. 


Jacobian transformation. This trans¬ 
formation from image features to robot 
joint angles is divided into three parts: 
the transformation from image features 
to camera coordinates, from camera co¬ 
ordinates to end-effector coordinates, 
and from end-effector coordinates to 
robot joint angles. This modular design 
allows changes to either the robot, the 
position of the camera with respect to 
the robot, or the image features without 
having to recompute the entire trans¬ 
formation. 

The differential transformation from 
image feature points to camera coordi¬ 
nates can be determined from the cam¬ 
era model described earlier under “Prob¬ 
lem statement.” The change in the 
position of a single feature point as a 
function of the change in the camera’s 
pose is given by 



c dx 

c dy 

c dz 

c &* 

c 5y 

c 8z 


where ('dx t ,'dy,) is the differential change 
in the image position of a feature point, 
‘J c ( c p,) is a 2 x 6 Jacobian matrix, ( c dx, 
c dy, c dz) is the differential change in the 
(x, y, z) position of the workpiece with 
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respect to the camera, and ( z 8x , c Sy, c Sz) 
is the differential change in the rotation 
about the (x, y, z) axes of the camera. 7 

For control, we are interested in the 
inverse transformation. A unique in¬ 
verse may exist if the change in position 


of three noncolline.ar feature points is 
used. The selection of these points will 
be discussed later. It is important to 
note that the Jacobian matrix J J C de¬ 
pends on the position of the feature 
point with respect to the camera, c p,. 


Ideally, this position would be comput¬ 
ed every vision sampling time, using the 
location-determination method de¬ 
scribed in the sidebar. However, since 
we concluded that this approach takes 
too long for real-time implementation, 
we use the desired position of this fea¬ 
ture point as determined from the off¬ 
line feature selection module to com¬ 
pute the Jacobian. Convergence occurs 
as long as the actual image features are 
sufficiently close to the desired image 
features. 7 

The differential transformations from 
camera coordinates to robot joint coor¬ 
dinates depend on the location of the 
camera (see Figure 4). For camera A 
mounted on the robot’s end-effector, a 
constant 6x6 Jacobian transformation, 
e J ca , can be defined from the camera 
coordinates to the robot’s end-effector 
coordinates. 1 This matrix will transform 
changes in the camera frame to changes 
in the robot’s end-effector frame. For 
an n degree-of-freedom robot, it is pos¬ 
sible to define a 6 x n Jacobian matrix, 
e J q (q), where q is a vector of robot joint 
angles representing the robot’s current 
configuration. This Jacobian matrix 
transforms changes in the robot joint 
angles into changes in pose in the ro¬ 
bot’s end-effector frame. 1 Since we are 
interested in the inverse solution, we 
will only consider a six degree-of-free¬ 
dom robot in a nonsingular position. 
Note that the Jacobian matrix e J q de¬ 
pends on the robot’s current configura¬ 
tion q. Since the current robot joint 
angles are passed back from the lower 
level joint controllers every 28 millisec¬ 
onds, the precomputed elements of the 
inverse matrix can be easily updated. 

Similarly for the stationary camera B, 
another constant 6x6 Jacobian trans¬ 
formation, °J cb , can be defined from the 
camera coordinates to the robot’s base 
coordinates. We use a different 6x6 
Jacobian matrix, °J q (q), to transform 
changes in the robot joint angles into 
changes in pose with respect to the base 
frame. 8 Again, this matrix can be updat¬ 
ed with the robot’s current position 
passed back from the lower level joint 
controllers. 

These differential transformations are 
formulated with the assumption that 
the changes in pose about an operating 
point are small. It has been shown that 
convergence to the desired state will 
occur if Jj' 1 is positive definite. 9 Here, J 
is the true Jacobian matrix (J = 'J c C J C • J q ) 
determined with the true parameters, 


Camera B 



Camera A: 


Aq = ( J q (q)) 1 e J ca ('J ca (“x, l) 1 A a f 
Camera B: 

Aq = (*il q (q)) 1 °J cb (J cb (° b x w )j 1 A 


Figure 4. Differential transformations from changes in feature point positions in 
the camera’s image coordinates to changes in the robot joint angles. 
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and J -1 is the inverse of the estimated 
Jacobian matrix determined with esti¬ 
mated parameters. If the Jacobians from 
the camera frame to robot joint coordi¬ 
nates, c J e and e J q , are assumed to be 
accurate, then the maximum allowable 
errors in camera parameter are where 
1 J (* J c ) _1 is positive definite. 

If the desired change is too large for 
convergence or to compensate for in a 
single sampling period, the feature-based 
trajectory generator 10 plans a trajectory 
from the extracted image features to 
the desired image features. The maxi¬ 
mum feature velocity of the trajectory 
generator is chosen so that changes in 
image features are within the limita¬ 
tions of the feature extraction process. 
This ensures a smooth motion without 
pauses for lost features. The smooth 
motion also minimizes image distortions 
caused by moving the camera in a jerky 
fashion. 

Image feature-based trajectory gen¬ 
erator. Figure 5 illustrates how to plan a 
feature-based trajectory. At time f 0 , a 
feature f(t 0 ) is extracted from the image. 
A trajectory is planned from this ex¬ 
tracted feature to the desired feature f d 
with the constraint that the feature ve¬ 
locity (first derivative of the feature 
position), feature acceleration (second 
derivative), and jerk (third derivative) 
are continuous at t 0 . This boundary con¬ 
dition ensures that the robot’s motion is 
smooth. Since the resolved motion-rate 
control structure uses velocity (or small 
changes over a time interval), continu¬ 
ity in feature position is not important. 

This feature-based trajectory gener¬ 
ator allows for nonuniform sampling of 
the vision system. Before the motion is 
completed, the feature extraction mod¬ 
ule can give the trajectory generator an 
updated feature position at a later time 
t x . The trajectory generator can then 
plan a new path as before. 

Image feature extractor. Our current 
feature extractor consists of a set of 
image processing boards and a host com¬ 
puter. The image processing boards can 
perform real-time (33-millisecond) con¬ 
volutions and lookup table operations 
on region-of-interest windows in an 
image. The host computer extracts the 
position of circles, corners, and line end 
points from the processed image. For 
very simple feature verification as de¬ 
scribed in the experimental results sec¬ 
tion, this extraction process in our sys¬ 


tem can be as short as 60 to 70 millisec¬ 
onds. As image processing equipment 
improves, we envision several image 
processing boards arranged in parallel 
and extracting different types of image 
features in real time. We could increase 
their throughput by using the planned 


feature-based trajectory to help esti¬ 
mate where to locate the image fea¬ 
tures. 

Off-line feature selector. This is the 
final component of our control struc¬ 
ture for visual feedback. Currently, we 


Implementation of the teach-by-showing method 


Researchers have used programming methods ranging from natural-language inter¬ 
faces to object-level robot languages to teach and program robot vision systems. 

These languages are intended to program the robot to move as required and use its 
sensors periodically to verify completion of a task. 

As an alternative to programming, teach-by-showing methods often use teaching 
devices to guide the robot and tell the sensors when to become active. 1 The teach- 
by-showing program implemented at Purdue University is a menu-driven program with 
teaching and playback modes. 2 The program lets the user teach the robot desired mo¬ 
tion commands and generate reference vision-feature data. The robot motion com¬ 
mands and the feature reference data are stored together in a file. In the playback 
mode, the system reads the file, executes the motion commands, and visually servos 
the robot until the extracted feature data correspond to the reference data. The sys¬ 
tem is currently limited to two cameras: a stationary camera above the robot work¬ 
space and a moving camera on the robot’s end-effector. 

Two types of sensor-based motion are available in the teaching mode: absolute and 
relative. The absolute-motion teaching mode uses the stationary camera and abso¬ 
lute-visual-feedback technique to locate an object and move the robot’s end-effector 
to a position relative to the object. While teaching, the system prompts the user for a 
feature-extraction process that will uniquely identify a single figure in the image. Typi¬ 
cally, the process thresholds the image, performs crack tracing around the black and 
white objects in the image, and identifies the objects by using Fourier descriptor coef¬ 
ficients (FDCs). 3 After the user selects the feature-extraction process and extracts a 
single figure (for example, the outline of a 
carburetor gasket in our experiments), the 
program displays the image on the work¬ 
station and asks the user to point with the 
mouse to the desired (x, y) position of the 
gripper. The user is also prompted for the 
desired x-y plane orientation and the z dis¬ 
tance of the gripper above the table. 

From this data and a precomputed cali¬ 
bration transformation, the workstation 
computes the pose of the part with respect 
to the robot’s base coordinates, the relative 
pose of the gripper with respect to the part, 
and the pose of the gripper with respect to 
the robot’s base coordinates. The gripper’s 
relative pose with respect to the part is 
saved for the playback mode. Its pose with 
respect to the robot’s base coordinates is 
sent to the robot controller, which moves 
the robot to the desired pose using a tra¬ 
jectory in joint coordinates. We used this 
mode in our experiments to locate a carbu¬ 
retor gasket in robot coordinates and move 
the robot end-effector to a position relative 
to the center of the gasket. 

The sensor-based relative-motion mode 
uses the robot camera and the differential 
visual-feedback technique to servo the 
gripper over an object. Figure B shows a 
flowchart of this teaching process. The rel¬ 
ative-motion teaching mode begins by dis- Figure B. Flowchart of teach-by-showing 
playing the names of the objects in the pro- method for different visual feedback. 
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use a teach-by-showing method to gen¬ 
erate the features that will be seen at vari¬ 
ous stages of the task. The sidebar ex¬ 
plains this method in more detail. From 
this set of possible image features, we 
select combinations of three image fea¬ 
tures based on a weighted function with 


both control and image processing crite¬ 
ria. 7 The control criteria ensure that fea¬ 
tures are selected to make the desired 
degrees of freedom observable and the 
control least sensitive to image noise. 
The image processing criteria minimize 
the time of feature extraction. 


As an example of one very important 
control criterion, the image features must 
be chosen so that the inverse Jacobian 
relationship between image features and 
camera coordinates exists and is well con¬ 
ditioned. The condition number of a 6 x 6 
Jacobian matrix from the camera space 



gram’s geometric database and prompting the user for the ob¬ 
ject to be tracked. (Spatial information about the object must 
be known a priori for a single camera to track an object mov¬ 
ing in all six degrees of freedom.) Next, the system prompts 
the user for the feature-extraction process. After extracting 
the features, the user has the option of moving the robot and 
automatically repeating the feature-extraction process. If the 
user is training a sequence of motions, the process may be 
repeated several times. 

Upon exiting this mode, the feature-selection process 4 is 
used to make a reference feature-lookup table for the play¬ 
back mode. The data structures in Figure C are used to store 
the image information, the geometric information, and the fea¬ 
ture lookup table. The image features and geometric features 
are stored in tree structures. When an image feature is 
matched to a geometric feature, a double link is formed be¬ 
tween them. The location-determination process uses the link 
from an image feature to a geometric feature to determine the 
3D distances between features. 

The playback mode uses the link from a geometric feature 
to an image feature. A single geometric feature may have 
several links to multiple image features from several different 
images. The feature selection lookup table points to the geo¬ 
metric features, which in turn point to the stored reference 
features. 


Figure C. Data structures quickly veri¬ 
fy the workpiece’s image features. 

The feature-selection table points to 
the geometric features, which in turn 
point to the learned desired image 
features. 
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grayjevel x_image_position yjmage_position image_orientation #FDCs 
list_of_FDCs 

) 

(move .relative JoJeature object_height x_position y_position orientation) 

) 

(wait_until_motion_is_complete) 

(perform_a_differential_sensor_based_motion 
(objectjs gasket) 

(use_the_robot_camera 

(take_a_picture) 

(thresholdjmage high_value low_value) 

(findjeatures 

(find_circles grayjevel ffcircles minimum_radius maximum_radius 
circle_name grayjevel xJmage_position yJmage_position radius 


Figure D. Pseudocode file 
used in playback mode. 


24. 

25. 

26. 
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to the feature space (with three feature 
points) can be used as a measure of this 
criterion. By minimizing this measure, we 
ensure that displacement of the workpiece 
is observable. An example of an ill-condi¬ 
tioned set of image feature points is three 
collinear points. It is impossible to observe 


While teaching the robot and sensors a sequence of operations, 
the program is storing the robot commands and sensor reference 
features in a file in Lisp-like syntax. The playback mode uses this file 
to direct the robotic system. Figure D shows a pseudocode example 
of a file that directs the robot to servo over the carburetor gasket 
and insert two pegs through two holes in the gasket. The first 15 
lines of the file instruct the robot to find the carburetor gasket on the 
table using the stationary camera. The rest of the file instructs the 
program to use the robot camera to visually servo the robot end-ef¬ 
fector until the error between the extracted image features and the 
reference features is within the desired tolerance. 

Two sets of image features were extracted. The first was at an ap¬ 
proach height above the gasket. The second was at the insertion 
point. The robot inserts the pegs by using the first set of features to 
servo to the appropriate approach position and using the second set 
of features to move into the holes. At the end of the teaching pro¬ 
cess, the extracted features were matched to the geometric data for 
the gasket, and the feature-selection criteria were used to select the 
best features for control. 

During playback, the program goes through the lookup table and 
chooses the first set of visible features. Figure E shows a flowchart 
of the playback mode. If a feature disappears during the servoing 
process, the program servos on the next set of features in the table. 
The ability to switch quickly between image features is important for 
tasks where partial occlusions are expected. 



27. (repeat_feature_extraction 

28. (find_circles grayjevel #circles minimum_radius maximum_radius 

29. circle_name grayjevel xJmage_position yJmage_position radius 


30. ) 

31. ) 

32. (matchedJeaturesJor_part = gasket 

33. (feature_set 0 

34. (matched_circles 

35. geometricJeature_name imagejeature name 


36. ) 

37. ) 

38. (feature_set 1 

39. (matched_circles 

40. geometricJeature_name imagejeature_name 


41. ) 

42. ) 

43. ) 

44. (selection Jable for part = gasket 

45. table_of_geometricJeature_names 

46. ) 

47. ) 

48. (quit_robot_motion) 

49. ) 


Figure E. Flowchart of differential 
visual feedback playback mode. 
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Figure 6. Above, experimental visual-servoing robot tracking the gasket as it 
moves through six degrees of freedom. Right, robot performing the pin-insertion 
task using visual feedback. 


a rotation of the workpiece about the 
line formed by these points from the 
displacement of the points in the image. 

An example of an image processing 
criterion might be the size of the fea¬ 
tures in the image. Larger features tend 
to be more robust, while smaller fea¬ 
tures tend to take less time to extract 
with existing hardware. The trade-off 
between robustness and time complex¬ 
ity must be carefully analyzed depend¬ 
ing on the system’s hardware and soft¬ 
ware, the environment of the task, and 
the task to be performed. 

Experimental results 

We tested this differential visual feed¬ 
back control structure with a Puma 600- 
series robot, two Pulnix T-540 charge- 
coupled device cameras, an Imaging 
Technology Itex-151 image processing 
system, a Sun 3/160 workstation, and a 
VAX 11/780 computer. The Itex-151 
performs low-level image processing 
routines such as Sobel operations and 
gray-scale thresholding. The Sun work¬ 
station extracts high-level features from 
the image through a memory mapping 
of the Itex frame buffers. These fea¬ 
tures are sent to the VAX over a 9600- 
baud serial line. A 28-millisecond inter¬ 
rupt routine on the VAX accepts feature 
data from the Sun, performs the fea¬ 
ture-based trajectory generation, trans¬ 
forms the changes in image features to 


changes in joint angles, adds these chang¬ 
es to the current joint angles, and sends 
the desired joint angles to the LSI-11/23 
robot controller. A special parallel in¬ 
terface between the LSI-11/23 and the 
VAX 11/780 was developed, and the 
VAX is used in a single-user mode. 
Every interrupt, the LSI and the VAX 
exchange desired and actual robot joint 
angles. 

We performed tests on tracking a car¬ 
buretor gasket with several holes of 
varying sizes (see Figure 6). We used 
the teach-by-showing program described 
in the sidebar to teach the system the 
desired pose of the gripper with respect 
to the gasket. During playback mode, 
the robot followed the gasket, keeping 
the gasket holes at the desired positions 
in the image. 

To minimize the image processing 
time, the system verified the location of 
three circles in the image by scanning 
out from the center of the last-known 
position in four directions until an edge 
was found. The center of the circle was 
then computed from the four edge points. 
The average vision sample time with 
this method was 60-70 milliseconds. If 
the edges were not found, more elabo¬ 
rate techniques such as crack tracing 
and Fourier descriptor coefficients 
(FDCs) were used within a small re- 
gion-of-interest window. If the circle 
was still not found, successively larger 
region-of-interest windows were 
searched. If more than one circle with 



the same approximate size was found in 
a region-of-interest window, the system 
would go to the next set of image fea¬ 
tures in the lookup table. 

Typically, there was approximately a 
100-millisecond delay between when the 
image was taken and when the control 
takes place. The sources of this delay 
are 33 milliseconds to acquire an image, 
33 milliseconds to analyze the image, 5 
milliseconds to send image feature data 
to the VAX computer, 28 milliseconds 
to transform the changes in features to 
changes in robot joint angles and relay 
the desired robot position to the LSI- 
11/23 robot controller. 

One of the tests tracked the gasket as 
it moved on a sloped conveyor belt. The 
speed of the conveyor belt was 2.7 cen¬ 
timeters per second in the y and z direc¬ 
tions of the world coordinates. While 
the conveyor belt was moving, the max¬ 
imum position errors in the x, y, and z 
directions were 18.4,21.6, and 8.0 milli¬ 
meters, respectively. The maximum ori¬ 
entation errors in roll, pitch, and yaw 
were 1.5, 2.6, and 2.2 degrees, respec¬ 
tively. More detailed experimental re¬ 
sults are described in Feddema et al. 7 
When the conveyor belt stopped, the 
robot moved to the desired steady state 
position relative to the gasket. 

The theoretical accuracy of the sys¬ 
tem to a single pixel error in one of the 
feature points can be determined from 
the elements of the inverse Jacobian 
matrix. Computing the inverse Jacobi- 
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an about the desired operating point 
(three gasket circles forming a triangle 
at 200 millimeters below the camera), 
the theoretical maximum position er¬ 
rors in the x, y, and z directions are 3.0, 
6.4, and 0.7 millimeters, respectively. 
The maximum orientation errors in roll, 
pitch, and yaw are 1.7, 0.8, and 0.2 de¬ 
grees, respectively. The difference be¬ 
tween the theoretical and experimental 
positioning accuracies was the result of 
the smoothing operation performed by 
the trajectory generator. In the future, 
as vision sampling time and servo reac¬ 
tion time decrease, accuracy will ap¬ 
proach the theoretical limits. 


W hile our research has shown 
the potential of model-based 
visual feedback control for a 
hand-eye coordinated robotic system, 
real-time visual servoing for industrial 
use is still several years away. The dem¬ 
onstrated system has limited capabili¬ 
ties and often lacks the robustness nec¬ 
essary for industrial tasks. We are 
continuing research on both hardware 
and software issues. 

There are two hardware bottlenecks 
in the current implementation. The first 
is the need to quickly extract robust 
features from an image. The second is 
the communication between the robot 
and the vision modules. A topic for 
software research is off-line simulation 
of the teaching phase. The objective 
would be to use CAD data instead of 
teach-by-showing methods to select the 
appropriate features for control. By 
using the CAD model, an entire assem¬ 
bly process could be planned off-line, 
thus eliminating the nonproductive time 
necessary for teaching. ■ 

Acknowledgments 

This work was supported in part by an 
IBM research fellowship and in part by the 
National Science Foundation under Grant 
No. CDR 8803017 to the Engineering Re¬ 
search Center for Intelligent Manufacturing 
Systems. Any opinions, findings, and conclu¬ 
sions or recommendations expressed in this 
article are those of the authors and do not 
necessarily reflect the views of the funding 
agencies. 

References 

1. R.P. Paul, Robot Manipulators: Mathe¬ 
matics, Programming, and Control, MIT 
Press, Cambridge, Mass., 1981. 


2. R. Tsia, “A Versatile Camera Calibra¬ 
tion Technique for High-Accuracy 3D 
Vision Metrology Using Off-the-Shelf TV 
Cameras and Lenses,” IEEE J. Robotics 
and Automation, Vol. RA-3, No. 4, Aug. 
1987, pp. 323-344. 

3. A.C. Sanderson and L.E. Weiss, “Adap¬ 
tive Visual Servo Control of Robots,” 
reprinted in Robot Vision, A. Pugh, ed., 
London: IFS Publications Ltd., pp. 107- 
116,1983. 

4. D.E. Whitney, “The Mathematics of Co¬ 
ordinated Control of Prosthetic Arms 
and Manipulators,” Trans. ASME, J. of 
Dynamic Systems, Measurement, and Con¬ 
trol, Vol. 122, Dec. 1972, pp. 303-309. 

5. S. Arimoto and F. Miyazaki, “Stability 
and Robustness of PID Feedback Con¬ 
trol for Robot Manipulators of Sensory 
Capability,” Proc. Int’l Symp. Robotics 
Research, MIT Press, Cambridge, Mass., 
1983, pp. 783-799. 

6. L.E. Weiss, A.C. Sanderson, and C.P. 
Neuman, “Dynamic Sensor-Based Con¬ 
trol of Robots with Visual Feedback,” 
IEEE J. of Robotics and Automation, 
Vol. RA-3, No. 5, Oct. 1987, pp. 404-417. 

7. J.T. Feddema, C.S.G. Lee, and O.R. 
Mitchell, “Weighted Selection of Image 
Features for Resolved Rate Visual Feed¬ 
back Control,” IEEE Trans. Robotics and 
Automation, Vol. 7, No. 1, Feb. 1991, pp. 
31-47. 


8. K.S. Fu, R.C. Gonzalez, and C.S.G. Lee, 
Robotics: Control, Sensing, Vision, and 
Intelligence, McGraw-Hill, 1987. 

9. C. Samson, M. Le Borgne, and B. Espiau, 
Robot Control: The Task Function Ap¬ 
proach, Oxford Univ., New York, 1991, 
pp. 218-235. 

10. J.T. Feddema and O.R. Mitchell, “Vision 
Guided Servoing with Feature-Based Tra¬ 
jectory Generation,” IEEE Trans. Ro¬ 
botics and Automation, Vol. 5, No. 5, 
1989, pp. 691-670. 



John T. Feddema is a senior member of the 
technical staff at Sandia National Laborato¬ 
ries in Albuquerque, New Mexico. He has 
worked in the Intelligent Systems Sensor and 
Controls Department on the control of flex¬ 
ible robotic structures and multisensor inte¬ 
gration of chemical and radiological sensors 
for nuclear waste characterization. Additional 
research interests include robotics, comput¬ 
er vision, sensor-based control, and comput¬ 
er-integrated manufacturing. 


Feddema received the BSEE degree from 
Iowa State University in 1984 and the MSEE 
and PhD degrees from Purdue University in 
1986 and 1989, respectively. He is a member 
of the IEEE. 



C.S. George Lee is a professor in the School 
of Electrical Engineering, Purdue Universi¬ 
ty, West Lafayette, Indiana. His research in¬ 
terests include computational robotics, intel¬ 
ligent multirobot assembly systems, and fuzzy 
neural networks. 

Lee received his BS and MS in electrical 
engineering from Washington State Univer¬ 
sity in 1973 and 1974, respectively, and his 
PhD from Purdue University in 1978. He is 
vice president of technical affairs for the IEEE 
Robotics and Automation Society, technical 
editor of the IEEE Transactions on Robotics 
and Automation, associate editor of the In¬ 
ternational Journal of Robotics and Automa¬ 
tion, coauthor of Robotics: Control, Sensing, 
Vision, and Intelligence, and coeditor of Tu¬ 
torial on Robotics, Second Edition. He is a 
senior member of the IEEE. 



O. Robert Mitchell is professor and chair of 
electrical engineering at the University of 
Texas at Arlington. He previously taught at 
Purdue University where he also served as 
assistant dean of engineering for industrial 
relations and research, and associate director 
of the National Science Foundation’s Engi¬ 
neering Research Center for Intelligent Man¬ 
ufacturing Systems. His research interests 
are in automated inspection, reverse engi¬ 
neering, intelligent material handling, robot¬ 
ic surface finishing, shape and texture analy¬ 
sis, and precision measurements in images. 

Mitchell received the BSEE from Lamar 
University in 1967 and the SMEE and PhD 
degrees from MIT in 1968 and 1972, respec¬ 
tively. He served as vice chair of the Midcon/ 
90 Technical Program Committee and secre¬ 
tary/treasurer of the Central Indiana chapter 
of the IEEE Computer Society. He is a senior 
member of the IEEE. 


Readers may contact John Feddema, at 
Sandia National Laboratories, Department 
1611, PO Box 5800, Albuquerque, NM 87185; 
e-mail, feddema@cs.sandia.gov. 


August 1992 


31 










B AD VANCE PROGRAM 

Fifth International Conference 
on Architectural Support for 
Programming Languages 
and Operating Systems 



SIGARCH 

SIGPLAN 

SIGOPS 


October 12-15,1992 

Boston, Massachusetts 

Sponsored by the ACM 
in cooperation with the 
IEEE Computer Society 



TC MM 
TC VLSI 
TC OS 


Monday, October 12 

Tutorial I: “High-Performance Shared Memory: Implemen¬ 
tation Issues and Consistency Models,” Sarita V. Adve and 
Mark D. Hill, Unviersity ofWisconsin-Madison 
Implementation options for high-performance shared-memory will 
be surveyed, including program sharing patterns (e.g., read-mostly 
and migratory), reducing memory latency with cache coherence 
(e.g., by snooping, directories or software), tolerating memory la¬ 
tencies with prefetching or multiple contexts. Hardware shared 
memory systems will be contrasted with shared virtual memory sys¬ 
tems. Theoretical and practical issues regarding memory consistency 
models will be explored, including the performance potential and 
ease-of-use aspects of sequential consistency and several weaker 
models (e.g., processor consistency, weak ordering, release consis¬ 
tency, and SPARC's TSO and PSO). 

Tutorial H: “Instruction-Level Parallel Processing: Superscalar 
Processor Design,” John Paul Shen, Carnegie Mellon 
University 

This tutorial presents the hardware and software techniques for su¬ 
perscalar processor design. Topics covered include: superpipelined, 
superscalar, supersymmetric and VLIW machines; limits of instruc¬ 
tion-level parallelism (ILP); dynamic techniques for detecting and 
resolving data and control dependencies (e.g. scoreboarding, regis¬ 
ter renaming, load bypassing and forwarding, branch prediction, and 
out-of-order/speculative execution); static techniques for depen¬ 
dency resolution (e.g. instruction boosting, and instruction schedul¬ 
ing for predicated/speculative execution); and recent quantitative 
experimental results on limits of these techniques for future super¬ 
scalars. We will survey current superscalar designs, including: 
R4000, RS/6000, Supersparc, PA-RISC 7100, i960CA and Alpha; 
detailed instruction-level evaluation of the IBM RS/6000 and 
Multiflow TRACE/300. 

Tuesday October 13 

Welcome and Keynote Address, Butler Lampson, DEC 
Cambridge Research Lab 
Session I: File Systems, Chair: Randy Katz 
On-line Data Compression in a Log-structured File System, M. Bur¬ 
rows, C. Jerian, B. Lampson, and T. Mann, DEC SRC. 
Non-volatile Memory for Fast, Reliable File Systems. Satoshi 
Asami, Mary Baker, Etienne Deprit, Margo Seltzer, and John 
Ousterhout, U. C. Berkeley. 

Parity Declustering for Continuous Operation in Redundant Disk 
Arrays. Mark Holland and Garth Gibson, Carnegie Mellon. 
Session H: Software and Hardware for Prefetching, Chair: David 
Callahan 

Software Support for Speculative Loads. Anne Rogers and Kai Li, 
Princeton University. 

Reducing Memory Latency via Non-blocking and Prefetching 
Caches. Tien-fu Chen and Jean-Loup Baer, U. of Washington. 
Design and Evaluation of a Compiler Algorithm for Prefetching. 
Todd C. Mowry, Monica S. Lam and Anoop Gupta, Stanford 
University. 

Session IH: Branch Prediction, Chair: Thomas Gross 
Exploiting the Accuracy of Dynamic Branch Prediction. Shien-Tai 
Pan and Kimming So, IBM , and Joseph T. Rahmeh, U.T. Austin. 
Predicting Conditional Jump Directions from Previous Runs of a 
Program. Joseph A. Fisher and Stefan M. Freudenberger, 
Hewlett-Packard Labs. 


Session IV: Networks and Communications, Chair: Anant 
Agarwal 

High Speed Switch Scheduling for Local Area Networks. Tom An¬ 
derson, U.C. Berkeley, and Susan Owicki, James Saxe, and 
Charles Thacker, DEC SRC. 

A Tightly-Coupled Processor-Network Interface. Christopher Joerg 
and Dana Henry, MIT. 

Evening Panel Session and Open Bar 


Wednesday October 14 

Session V: Caches and Memory Management, Chair: Douglas 
Clark 

Virtual Memory Management for Virtually Addressed Write-Back 
Caches. Bob Wheeler and Brian Bershad, Carnegie Mellon. 

Eliminating the Address Translation Bottleneck for Physical Ad¬ 
dress Cache. Tzi-cker Chiueh and Randy Katz, U.C. Berkeley. 

A Performance Evaluation of Optimal Hybrid Cache Coherency 
Protocols. Jack E. Veenstra and Robert J. Fowler, Univ. of 
Rochester. 

Session VI: Architecture and Operating Systems, Chair: John 
Wilkes 

Characterizing the Caching and Synchronization Performance of a 
Multiprocessor Operating System. Josep Torrellas, Anoop Gupta 
and John Hennessy, Stanford. 

Architectural Support for Single Address Space Operating Systems. 
Eric J. Koldinger, Jeffrey S. Chase, and Susan J. Eggers, Univ. 
of Washington. 

Application-Controlled Physical Memory using External Page- 
Cache Management, Kieran Harty and David Cheriton, Stanford. 

Session VII Miscellaneous Topics, Chair: Anita Borg 

Write Monitors Towards an Efficient Data Breakpoint Service. 
Robert Wahbe, U.C. Berkeley. 

Migrating a CISC Computer Family onto RISC via Object Code 
Translation. Kristy Andrews and Duane Sand, Tandem Com¬ 
puter Corporation. 

Fast Mutual Exclusion for Uniprocessors. Brian N. Bershad, 
Carnegie Mellon, and David D. Reed and John R. Ellis, DEC 
SRC. 

Session VIH: Work in Progress Session, Chair: Susan Eggers 

Evening Panel Session and Open Bar 

Thursday October 15 

Session IX: Superscalars, Chair: Mary Lou Soffa 

Sentinel Scheduling for VLIW and Superscalar Processors. Scott A. 
Mahlke, William Y. Chen, and Wen-mei W. Hwu, Univ. of Illi¬ 
nois, and B. Ramakrishna Rau and Michael S. Schlansker, 
Hewlett-Packard Labs. 

Efficient Superscalar Performance Through Boosting. Michael D. 
Smith, Mark Horowitz, and Monica Lam, Stanford. 

Session X: Multiprocessors: Hardware and Software, Chair: 
David Cheriton 

Cooperative Shared Memory: Software and Hardware Support for 
Scalable Multiprocessors. Mark D. Hill, James R. Larus, Steven 
K. Reinhardt, and David A. Wood, Univ. of Wisconsin. 

Closing the Window of Vulnerability in Multiphase Memory Trans¬ 
actions. John Kubiatowicz, David Chaiken, and Anant Agarwal, 
MIT. 

Access Normalization: Loop Restructuring for NUMA Compilers. 
Wei Li and Keshav Pingali, Cornell University. 












Work in Progress Session 

This year ASPLOS will feature a "work in progress" session, 
consisting of 5-minute presentations on ASPLOS-oriented work in 
progress, or even opinions about technical (and certainly controver¬ 
sial) topics. If you are interested in participating, please send an ab¬ 
stract of no more than one page to Susan Eggers, preferably through 
email (eggers@cs.washington.edu) or at Dept, of Computer Science 
and Engineering, Univ. of Washington, Seattle, WA 98195. Your 
abstract must be received by September 15, 1992; final notification 
will be just prior to the conference. 

As is customary for ASPLOS, there will be panel sessions in 
the evenings on controversial and/or topical subjects. This year there 
will be a reception on Monday evening and panels on both Tuesday 
and Wednesday evenings. An open bar will be available during both 
panel sessions. 

Conference Chairs 

General Barry Flahive, Hewlett-Packard 

Program Hank Levy, University of Washington 

Treasurer Bob Nix, Digital Equipment Corporation 

Publicity Jeanette McWilliams, IBM 

Local Arrangements David Levine, Hewlett-Packard 
Registration Hugh Lauer, Mitsubishi Electric Research 

Tutorials Bruce Olsen, Hewlett-Packard 

Program Committee 

Hank Levy 
Anant Agarwal 
Anita Borg 
David Callahan 
David Cheriton 
Doug Clark 
David Ditzel 
Susan Eggers 
Thomas Gross 
Randy Katz 
David May 
Mary Lou Soffa 
Guy Steele 
John Wilkes 

Registration 

Conference registration includes one copy of the proceed¬ 
ings, lunches, breaks, banquet, and receptions. Registration for 
tutorial sessions includes both tutorials plus one copy of notes 
for each tutorial, a lunch, and breaks. 

Electronic mail or fax registration requires payment by 
credit card. A registration form may be retrieved by anonymous 
ftp from merl.com, file /asplos/registration.form. 

For further information, contact Darlene Forsyth at (508) 
436-5450 or asplos@apollo.hp.com. 

Conference Site and Accomodation 

All technical sessions, lunches, and registration will be held 
at the Boston Park Plaza Hotel and Towers, 64 Arlington Street, 
Boston, Massachusetts 02117; phone (617) 426-2000. 

Transportation 

Boston’s Logan Airport is located very near downtown and 
the Park Plaza Hotel. Airways Transportation operates a shuttle 
from the airport every half hour to all downtown hotels; fare is 
$7.50. A taxi cab costs about $12-15 and takes 20-40 min- 
utes.Visitors may also take the MBTA bus and subway. The ho¬ 
tel is located one block from the Arlington Station on the Green 
Line, and three blocks from the Amtrak Back Bay Station. 

Climate 

Weather in Boston in October ranges from chilly to warm. 
Early morning temperatures may be as low as 35° F, but tem¬ 
peratures may rise to the upper 70°s F during the day. A jacket 
will probably be needed, and rain is always a possiblity. Casual 
attire is appropriate throughout the conference. 


University of Washington (chair) 
MIT 

DEC Western Research Lab 
Tera Computer Corporation 
Stanford University 
Digital Equipment Corporation 
Sun Microsystems 
University of Washington 
Carnegie Mellon University 
Univ. of California, Berkeley 
INMOS Limited 
University of Pittsburgh 
Thinking Machines Corporation 
Hewlett-Packard Laboratories 


ASPLOS-V Registration Form 
ASPLOS-V 
P.O. Box 1455 
Concord, MA 01742 
(617) 621-7503; Fax: (415) 621-7550 
Attention: Hugh Lauer 


Name: . 

Affiliation: 
Address: .... 


Daytime telephone: . 

□ ACM □ IEEE Member no.: 
Electronic mail address: . 


Please list any special needs or accommodations ... 


Member^ 

Non-Membert 

Studenttt 

□ $295 

□ $413 

□ $120 

□ $205 

□ $287 

□ $97 

□ SmaU 

□ X-Large 

□ Medium 

□ Large 

Member 

Non-Member 

Student^ 

□ $398 

□ $558 

□ $120 

□ $277 

□ $387 

□ $97 


(Before Sept 14) 

Symposium 

Tutorial 

T-Shirt Sizet 


(After Sept 14) 

Symposium 

Tutorial 


t ASPLOS T-shirt included with advance registration only, 
tt Student registration must be accompanied by a copy of a valid, 
full-time student ID; meals not included __ 

D Check drawn on U.S. bank payable to: ASPLOS-V 
□ Master Card□ Visa 

Card no.; ...... 

Expiration date: . 

Name on card: . . 

Signature: . 


Hotel Reservatons 

Contact hotel directly for reservations and indicate 
ASPLOS-V Conference. Conference rates are $105 for single 
and $115 for double, (9.7% State and City tax not included). 
Reservations must be received by September 14, 1992, to 
guarantee conference rate. Late reservations accepted on a 
space-available basis. 

Boston Park Plaza Hotel 
64 Arlington Street 
Boston, MA 02117 
(617) 426-2000; Fax: (617) 426-5545 


Register early for a free ASPLOS T-shirt. 






























Architectural Support 
for Goal Management 
in Flat Concurrent Prolog 


Leon Alkalaj, Jet Propulsion Laboratory, California Institute of Technology 

Tomas Lang, Polytechnic University of Catalonia 

Milos D. Ercegovac, University of California at Los Angeles 


The proposed 
architectural support 
for goal management 
is part of a special- 
purpose processor 
architecture for the 
efficient execution of 
Flat Concurrent Prolog. 


A logic program can be described as a set of conjunctive (AND) and 
; disjunctive (OR) constraints imposed on the values assigned to the logical 
: variables defined in the program. These constraints can be conveniently 
expressed in the form of a tree of AND-OR relations. 1 Program execution then 
consists of traversing this tree and finding one or more consistent sets of bindings 
for all the logical variables in the program. A consistent binding set represents a 
solution to the logic program. 

Languages such as Prolog define an implicit search of the tree using both forward 
and backward program continuations. During forward continuation, all changes to 
the runtime environment are saved; this is done so that changes can be restored 
whenever an inconsistency in the binding set results in backward continuation 
(backtracking). 

Committed-choice execution. In contrast to multiple-solution logic program¬ 
ming languages, Flat Concurrent Prolog (FCP) commits to a single binding set for 
the program’s logical variables, thus returning only a single solution. This commit¬ 
ted-choice execution defines only forward — not backward — program continua¬ 
tions. Moreover, in selecting a forward continuation path, FCP uses only pre¬ 
defined test predicates to inspect the runtime environment. 

The flat attribute of FCP indicates that forward selection does not involve the 
nesting of programming environments. 2 Other flat committed-choice languages 
include Flat Parlog and Flat GHC. (Shapiro presents a detailed review of the 
family of concurrent logic programming languages. 3 ) 

Logical goals. The committed-choice nature of FCP results in application areas 
distinct from those suitable to multiple-solution logic programming. FCP is being 
used as an algorithmic language for parallel programming. The main unit of 
concurrency is a logical goal, and shared logical variables are used as communica¬ 
tion channels. 

An FCP program typically creates numerous concurrent goals that represent a 
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set of conjunctive constraints on the 
bindings of the logical variables. The 
conjunctive relation implies that all goals 
have to reduce for the program to suc¬ 
cessfully terminate and that the order in 
which they reduce is nondeterministic. 

A goal reduction can create new goals, 
asynchronously communicate variable 
bindings to other goals, and terminate 
execution. Synchronization is performed 
by sending and receiving messages that 
result in goal-suspension and data- 
driven goal-activation. An analogy can 
be drawn between a logical goal in FCP 
and processes in a multitasking system, 
or concurrent threads of execution in a 
task. 2 

Current implementations of FCP on 
general-purpose single processors em¬ 
ulate the execution of a sequential ab¬ 
stract machine defined by Flouri and 
Shapiro. 4 Their machine is based on the 
Warren abstract machine for Prolog, 5 
but is modified to support intergoal com¬ 
munication. It uses a queue to imple¬ 
ment the nondeterministic scheduling 
of goals and allocates all runtime data 
and control structures from a heap. This 
contrasts with the stack-oriented run¬ 
time architecture in the Warren abstract 
machine. 

Goal management. In earlier work, 6 
we analyzed FCP program execution at 
the abstract machine level to determine 
algorithmic properties for a specific 
workload, the systems development 
workload. SDW is characteristic of an 
environment used for prototyping and 
developing concurrent systems. It com¬ 
prises seven large programs, which in¬ 
clude the Logix operating system, com¬ 
piler, debugger, program analyzer, and 
three simulators. All programs are rep¬ 
resentative of a working environment 
in current use. Our analysis showed that, 
on the average, a goal 

• performs a small number of reduc¬ 
tions (2-3) prior to termination, 

• suspends waiting for data commu¬ 
nicated by other goals, and 

• activates goals when the data ar- 


In addition, a goal synchronizes reduc¬ 
tion with other goals by waiting for sev¬ 
eral messages at a time; similarly, a sin¬ 
gle message activates several goals. 

In other words, the communication 
structure and behavior of goals can be 
characterized as tightly coupled. More- 


Glossary of terms 

CAP: Current active pointer 
CSP: Current spawn pointer 
DC: Data cache 
FCP: Flat Concurrent Prolog 
GC: Goal cache 
GM: Goal memory 
GMC: Goal-management controller 
GMP: Goal-memory port 
GMR: Goal-memory management 
registers 

GMU: Goal-management unit 
GQB: Goal queue back 
GQF: Goal queue front 
GSB: Goal-status bit 
HP: Heap pointer 
1C: Instruction cache 
IU: Instruction unit 
NAP: Next active pointer 
NSP: Next spawn pointer 
RU: Reduction unit 
SDW: Systems development 
workload 

ST: Suspension table 
TU: Tag unit 
WP: Window pointer 
WQ: Wakeup queue 


over, the average granularity of a goal 
was counted as several hundred RISC 
instructions (single-cycle register- 
register instructions), thus implying very 
fine granularity compared to tradition¬ 
al (Unix style) processes. Therefore, a 
goal in SDW is characterized as a fine- 
grain computation tightly coupled with 
other goals in the program. 

Due to the large number of goals as 
well as their fine granularity, the over¬ 
head of goal management is significant. 
Moreover, in a general-purpose imple¬ 
mentation of FCP, the relative execu¬ 
tion time of software-implemented goal 
management increases as goal reduc¬ 
tion is made more efficient (using com¬ 
pile-time program analysis). 

A specialized architecture that sup¬ 
ports goal reduction using dedicated 
instructions further increases the rela¬ 
tive execution time of goal management. 
Using a special-purpose instruction set 
and executing the SDW, almost 50 per¬ 
cent of the execution time is spent per¬ 
forming goal-management operations. 7 
These results strongly motivate the use 
of special-purpose architectural support 
for goal management. 


In this article, we 

• Describe architectural support for 
goal management as part of a spe¬ 
cial-purpose processor. 8 

• Decouple goal-management opera¬ 
tions from goal-reduction operations 
and overlap them in a separate goal- 
management unit (GMU). 

• Perform efficient goal management 
using a goal cache (GC) that stores 
recently spawned goals. 

• Evaluate the performance of the 
GMU using an analytic model. 

• Determine program parameters of 
the model using an instrumented 
version of the Logix operating sys¬ 
tem executing the SDW. Using the 
GMU, most goal-management op¬ 
erations are completely overlapped 
with goal reduction, resulting in a 
speedup of almost two. 

•Generalize our results for other 
workloads characterized by differ¬ 
ent goal-management complexities. 

The upper bound on the speedup due 
to the overlapped and efficient execu¬ 
tion is proportional to the relative exe¬ 
cution times of goal management and 
goal reduction. The behavior of FCP 
goals can be compared to other lan¬ 
guages based on concurrent, fine-grain, 
asynchronously communicating units of 
work such as Concurrent SmallTalk 9 or 
Actors. 10 The architectural support we 
propose for the execution of FCP con ¬ 
sists of hiding the latency of intergoal 
communication and synchronization by 
decoupling and overlapping them with 
continuous goal reduction. 

Flat Concurrent Prolog 
goals 

An FCP program is a set of condi¬ 
tional sentences called guarded clauses, 
which the programmer uses to declare 
all possible actions of a goal. A guarded 
clause is represented in the following 
form: H <- G I B., where H denotes the 
head of the clause, <- the implication 
operator, the guard G represents a set 
of conditions, I is the commit operator, 
and B the set of body goals. The declar¬ 
ative reading of a guarded clause is 
that goal H can be reduced to a new set 
of goals B, given that all of the condi¬ 
tions G are previously satisfied. For 
example, consider the actions of goal a 
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that consists of the following guarded 
clauses: 

a <- C„ C 2 1 b, c, d. 
a <- C 3 , C 4 1 a. 
a <r- C 5 |. 

The three clauses represent alterna¬ 
tive actions that can take place when 
goal a executes. Either 

• goal a reduces to goals b, c, and d if 
conditions C, and C 2 are satisfied; 

• goal a reduces to goal a if conditions 
C 3 and C 4 are satisfied (Note that 
this clause represents the iteration 
of goal a.); or 

• goal a reduces without creating new 


goals, if condition C 5 is satisfied — 
that is, terminates execution. 

The execution mechanism that dis¬ 
tinguishes FCP from noncommitted- 
choice logic programming languages is 
that only one clause may be used to 
reduce goal a. For example, if all condi¬ 
tions C t ,..., C s in the above example are 
satisfied, you can use any one of the 
clauses to reduce goal a. However, once 
execution commits to one clause, you 
don’t consider alternative clauses to 
reduce the same goal. That is, only the 
forward continuation of applied clauses 
is permitted in FCP. This feature makes 
FCP programming partially determin¬ 
istic. The nondeterminism still remains 


Goal suspension in Flat Concurrent Prolog 

A system of concurrent goals in Flat Concurrent Prolog shares logical variables 
as communication channels. In Figure A, goal a is reduced to goals b, c, and d ; 
goal e is communicating with goal f by sending three messages; and goals p and 
q are suspended, with p suspended on variable Zand q suspended on variables 
Y and Z. 

Goal suspension is implemented using linked-list data structures that enable a 
goal to suspend on several variables and several goals to suspend on a single 
variable. The suspension list pointer is stored in the variable location. 4 

In FCP, goal suspension occurs as a result of a goal-reduction attempt that nei¬ 
ther fails nor succeeds. Therefore, goal suspension occurs after it is guaranteed 
that no clause can be used for immediate goal reduction, but some clause may 
be applicable in the future when more data becomes available. If several clauses 
are applicable to the current goal, suspension occurs only after attempting all of 
them and finding that none succeed. This search for a successful clause is a po¬ 
tential source of goal-reduction overhead. 6 

A suspended goal is activated when another active goal produces the message 
that was the reason for suspension. This message is sent via the channel by 
making the channel point to it. If a goal is already suspended on this channel, the 
goal-suspension pointer is used to activate the goal before the message is sent. 



in the scheduling of goals and in the 
selection of clauses. 

In FCP, user annotation of shared 
variables discriminates between the 
sender and receiver of a message. For 
example, consider two goals b(X?) and 
c(X) that share the variable X. The read¬ 
only annotation of X denoted as XI 
implies that goal b cannot send a mes¬ 
sage via channel X\ it can only receive. 
However, goal c that shares the writ¬ 
able access to the channel can send a 
message. If, due to nondeterministic 
scheduling, goal b executes before goal 
c sends the message, goal b will suspend 
execution until the message is actually 
sent. The functionality of read-only vari¬ 
ables in FCP is similar to the use of 
futures in MultiLisp. 11 Both constructs 
allow the programmer to define and 
manage fine-grain concurrent program 
execution and synchronization. (See the 
sidebar for a detailed description of goal 
suspension in FCP.) 

FCP processor 
organization 

The FCP processor architecture con¬ 
sists of multiple functional units for ex¬ 
ecuting FCP programs. Its high-band¬ 
width memory enables concurrent 
manipulation of three types of objects: 
goals, tagged data, and instructions. As 
Figure 1 shows, the hierarchical struc¬ 
ture of the processor architecture con¬ 
tains tightly coupled execution units, 
specialized cache units, and dedicated 
memory modules. 

The reduction unit (RU) is the main 
instruction-set unit in the FCP proces¬ 
sor. It executes a RISC instruction set 
that supports pointer dereferencing, 
multiway branching, and the allocation 
of data structures on the heap. The RU 
is tightly coupled with the tag unit (TU), 
which concurrently performs tag decod¬ 
ing, setting, and extraction. The goal- 
management system supplies the RU 
with reducible goals and efficiently ex¬ 
ecutes all goal-management operations. 
It consists of the goal-management unit 
(GMU), the goal cache (GC), and the 
goal memory (GM). 

The instruction unit (IU) provides 
the execution units with executable in¬ 
structions. A single instruction contains 
separate opcode fields for each func¬ 
tional unit. The functionality of the ex¬ 
ecution units is partitioned so that the 
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Figure 1. Flat Concurrent Prolog processor multiple functional unit organization. 



Figure 2. 

Overlapped 
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unit/goal- 
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unit execution. 


RU manipulates only program data 
structures, the TU manipulates data tags, 
the GMU manipulates goal structures, 
and the IU manipulates instructions. 
The FCP processor has dedicated cache 
units — the instruction cache (1C), the 
data cache (DC), and the GC — that 
enable faster access to objects request¬ 
ed by the execution units. Objects are 
requested from the memory modules 
only on a cache miss. 

Memory is also divided into dedicat¬ 
ed sections that are accessed and man¬ 
aged only by the corresponding execu¬ 
tion unit. The data memory stores all 
program data structures such as lists, 
variables, tuples, and constants. The tag 
memory stores all the data tags. The 
instruction memory stores processor 
instructions. The GM stores control 
structures used for goal creation, sus¬ 
pension, activation, and termination. 

RU-GMU overlapped execution and 
synchronization. In an FCP implemen¬ 
tation based on the sequential abstract 
machine described in Houri and Shapi¬ 
ro 4 and executing on a general-purpose 
physical machine, FCP programs are 
translated to a sequence of goal-reduc¬ 
tion operations interleaved with high- 
level goal-management functions. Both 
goal-reduction and goal-management 
operations are thus executed sequen¬ 
tially. In the proposed architecture, goal- 
management operations are decoupled 
from goal-reduction instructions using 
a suspension table (ST) and a wakeup 
queue (WQ) (see Figure 2). During a 
goal reduction, the RU stores in ST 
addresses of the (read-only) variables 
on which the current goal can suspend. 
At goal suspension, the RU switches to 
an alternate ST, thus allowing the GMU 
to access the old ST and perform over¬ 
lapped goal suspension. A similar poli¬ 
cy applies to the use of a WQ. During 
goal reduction, the RU stores in WQ 
pointers to goals that can be activated if 
the current clause commits. If it does, 
goal reduction switches to an alternate 
WQ while the GMU activates goals 
based on the old WQ. 

The GMU executes four instructions: 
halt, spawn, suspend, and activate. Each 
instruction is a high-level operation, 
executing longer than single-cycle RU 
instructions. While the GMU executes 
the current goal-management instruc¬ 
tion, the RU continues executing subse¬ 
quent instructions fetched by the IU. 

If prior to termination of the current 


goal-management instruction the IU 
fetches another goal-management op¬ 
eration, the RU blocks until the GMU 
completes its operation. Therefore, only 
a single goal-management instruction is 
overlapped in the GMU. An alternative 
is for the GMU to maintain a queue of 
goal-management operations; howev¬ 
er, this would significantly increase the 
complexity of control. 

Goal-management 

system 

The purpose of the goal-management 
system is to reduce the contribution of 
the goal-management execution time 
to the overall program execution time. 
For a processor organization that does 
not have architectural support for goal 
management, this contribution is the 
time to execute processor instructions 


that implement goal-management func¬ 
tions. We reduce the goal-management 
execution time in the following comple¬ 
mentary ways: 

(1) Goal-management instructions 
are overlapped with goal-reduction in¬ 
structions. 

(2) Goal-management operations are 
efficiently implemented using a special- 
purpose goal cache. 

Goal-management unit. As Figure 3 
shows, the GMU consists of a goal-man¬ 
agement controller (GMC), a goal-mem¬ 
ory port (GMP), and goal-memory 
management registers (GMR). The ex¬ 
ecution of goal-management instruc¬ 
tions consists of managing goals stored 
in the goal cache (GC). 

The GMC uses a busy flag control 
signal to synchronize RU and GMU 
execution. When the GMU receives an 
instruction from the IU (assuming the 
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Figure 5. 

Reduction 
unit/goal-man- 
agement unit 
interface via 
goal-window 
pointers. 


GMU is not busy), the GMU busy flag is 
set. Subsequent instructions (fetched by 
the IU) that contain goal-management 
instructions are blocked until the flag is 
reset. When the GMU completes exe¬ 
cuting the current instruction, it resets 
the flag. Any pending instruction is then 
resumed. The separate memory port, 
the GMP, enables the transfer of goals 
between the GC and the GM, as well as 
the allocation of data structures used to 
implement goal suspension. 

The GMR contains five special-pur¬ 
pose registers used for dynamic man¬ 
agement of the GM: The heap pointer 


(HP) is used to allocate structures on 
the top of the heap; the goal-free list 
and suspension-free list pointers are 
used for reclaiming discarded control 
structures and are stored in the GFL 
and SFL registers respectively; and the 
GQF and GQB registers store pointers 
to the front and back of the goal queue 
in memory. 

Goal cache. A goal is represented as 
a data structure comprising a program 
counter and goal-argument pointers. For 
the systems development workload, a 
goal has an average of five arguments. If 


the program counter and additional con¬ 
trol information is included, a fixed goal 
size of 10 words would be sufficient for 
95 percent of all goal-record structures. 

The FCP compiler detects if a goal 
has more than the maximum number of 
arguments and compacts the remaining 
arguments into a single complex data 
structure that is dynamically expanded. 
This approach is used in the FCP se¬ 
quential abstract machine. 4 Having the 
same size for all goal-record structures 
makes dynamic management more effi¬ 
cient. 

The GC shown in Figure 4 consists of 
A goal windows used to store fixed-size 
goals. The GC also contains goal-status 
bits (GSBs) that denote the state of the 
goals stored in the GC and goal window 
pointers (WPs) that point to specific 
windows in the GC. Each goal window 
is implemented using 10 registers (see 
Figure 4). At each instant during pro¬ 
gram execution, only two windows are 
accessible to the RU, one containing 
the currently executing (active) goal and 
the other containing the currently spawn¬ 
ing goal. The remaining windows are 
accessible by the GMU. The status of a 
goal window can be 

•Active (A): Window contains the 
executing goal. 

•Spawn (S): Window is used for 
spawning. 

• Ready (R ): Window contains a goal 
ready for execution. 

• Free (F): Window is empty. 

There is always only one current ac¬ 
tive and one current spawn goal win¬ 
dow in the GC, whereas there can be 
many ready and free goal windows. Any 
goal window marked as ready can be 
selected as the next active goal, and any 
free window can be selected to be the 
next spawn window. 

The four registers — the current ac¬ 
tive pointer (CAP), current spawn point¬ 
er (CSP), next active pointer (NAP), 
and next spawn pointer (NSP) — con¬ 
tain pointers to the current active, cur¬ 
rent spawn, next active, and next spawn 
pointer windows, respectively. The RU 
uses the CAP to access the currently 
active goal and the CSP to spawn a new 
goal. If the GC contains several ready 
goals, goal-switching consists of chang¬ 
ing the CAP to an alternative ready 
window. Similarly, spawning a new goal 
consists of changing its status from spawn 
to ready, whereas terminating an active 
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goal consists of changing its status from 
active to free. 

The next goal pointer values, NAP 
and NSP, are always set by the GMU, 
while the RU reads them. The efficient 
interpretation of goal-management op¬ 
erations, as seen by the RU, is per¬ 
formed by managing the four goal point¬ 
ers (see Figure 5). 

To interpret goal termination or sus¬ 
pension, the RU moves the NAP to the 
CAP while the CSP remains the same. 
By prefetching an instruction from the 
next active goal stored in the window 
pointed to by NAP (and if there is no 
wait delay due to RU-GMU synchroni¬ 
zation), the goal-management instruc¬ 
tion is completely overlapped without 
contributing to the total program exe¬ 
cution time. While the RU starts to 
execute the newly scheduled goal, GMU 
performs the goal-management opera¬ 
tion and determines the new value for 
the NAP. For the spawn instruction, the 
NSP is moved to the CSP, whereas the 
CAP remains the same. The activate 
instruction does not affect the goal- 
pointer values. 

Two exceptional conditions are de¬ 
tected in the GC. First, GC-overflow 
occurs when the GC becomes full and 
there is no free window for spawning. 
Upon overflow, a goal is moved to the 
goal queue in GM. To implement effi¬ 
cient spawning of new goals, overflow is 
detected before the GC becomes com¬ 
pletely full. That is, there is always one 
empty goal window available for fast 
spawning. The second exceptional con¬ 
dition is GC-underflow, which occurs 
after a sequence of goal terminations 
depletes the GC of available goals for 
scheduling. To implement efficient ter¬ 
mination, at least one prefetched goal is 
always available in the GC. Thus, a new 
goal can be scheduled whenever the 
current goal terminates execution. Oth¬ 
erwise, the RU may need to wait until a 
new goal is fetched from the GM. 

Goal-management instructions imple¬ 
mented by manipulating only the goal 
status bits in the GC are considered 
cache hits. On the other hand, all goal- 
management instructions that require 
access to memory are interpreted as 
cache misses. 

As mentioned above, there are four 
goal-management instructions: halt, 
spawn, suspend, and activate. The fol¬ 
lowing reviews the algorithm for each. 
(See the sidebar for an example of pro¬ 
gram execution using goal windows.) 


Halt. Goal termination is always per¬ 
formed in the active goal window (CAP), 
and the next active goal is scheduled 
(NAP). When there is no cache under¬ 
flow, the active goal window is marked 
free and the next ready goal is marked 
active. The GMU determines the next 
ready goal by inspecting the GSB and 
then sets the NAP. On completion of 


the halt instruction, the GMU busy flag 
is reset. In case of underflow, a goal is 
prefetched from the goal queue in mem¬ 
ory and placed in any empty goal win¬ 
dow. For simplicity, it is stored in the 
same window as the terminated goal. 

Spawn. Spawning a new goal by the 
active goal is always performed in the 
CSP window. After placing the goal 


Program execution using goal windows 

The quicksort program (Figure B1) executes in the goal cache in three steps 
(Figures B2-4). The active goal window (Figure B2) contains the quicksort goal, 
which consists of the program counter PC-Q and two argument pointers, 41 
and 42. 

The first argument denotes the input list of elements [XIXs], and the second 
argument denotes the result variable Sort. CAP points to the active goal win¬ 
dow, CSP to the spawn window, NAP to the next ready goal, and NSP to the 
free window. The active goal spawns two quicksort goals, one partition, and 
one append goal. 

Spawning consists of moving argument pointers into the spawn window reg¬ 
isters. Following spawning of the partition goal, the active goal continues to 
spawn the next quicksort goal (Figure B3). As this goal is spawned, the GMU 
detects GC overflow, since there is only one free window left in the GC. During 
the spawning of the second quicksort goal (Figure B4), GMU determines where 
the next new empty window will be, and moves a ready goal from that window 
to the goal queue in memory. 

The vacated window is marked as free and can be used for spawning the 
next goal. 



(3) (4) 


Figure B. Executing part of the quicksort program (1) in the goal cache: (2) 
the spawn “partition”; (3) the spawn quicksort, goal cache overflow; and (4) 
the goal cache overflow, spawn quicksort. 


August 1992 


39 































































Figure 6. System 
organization. 

arguments in the spawn window regis¬ 
ters, the window is marked ready, and 
the next empty window is marked as 
spawn. The GMU then determines the 
next free window, sets the NSP, and 
resets the GMU busy flag. In case of 
overflow, any goal window is vacated 
from the GC. For simplicity, the most 
recently spawned goal is moved to 
memory. 

Suspend. The GMU implements goal 
suspension by accessing the suspension 


pointers stored in the ST. The RU switch¬ 
es to the new ST, and the GMU has 
exclusive access to the ST that contains 
the suspension pointers. The goal-sus¬ 
pension algorithm consists of moving 
the active goal from the GC to the GM 
and marking the empty window as free. 
However, if this results in underflow 
and there are goals in the GM, a goal is 
prefetched, and the window is marked 
as ready. 

Activate. The activate instruction de¬ 


notes the point during program execu¬ 
tion when goal reduction commits to a 
clause. If no assignments are made dur¬ 
ing a clause-try, or if assignments are 
made to variables that did not contain 
suspension pointers, the wakeup queue 
is empty and no goals are activated. 
Otherwise, previously suspended goals 
are enqueued onto the active goal queue 
in the GM, and suspension structures 
are garbage collected. 

Properties of GMU execution using a 

GC. Overlapping goal management with 
goal reduction using a GC has the fol¬ 
lowing properties: 

• Goals are always spawned in win¬ 
dow registers. Alternatively, goals would 
either be created in memory or first in 
registers and then moved to memory. 
Having both the active and spawn goals 
in registers increases the number of reg¬ 
ister operations and thus boosts perfor¬ 
mance. 

•The GMU maintains at least one 
empty goal window for spawning. Thus, 
the RU never allocates memory for a 
goal record. This is always done by the 
GMU, overlapped with goal reduction. 

• The GM is managed by the GMU, 
which performs dynamic garbage col¬ 
lection, overlapped with RU execution. 
Allocating goal-control structures in the 
same memory area as data results in 
frequent garbage collections that de¬ 
grade performance. 

• Some goals spawned in the GC ter¬ 
minate without being removed. In these 
cases, goal caching reduces the number 
of times memory is allocated. 

•The GC policy stores recently 
spawned goals on the processor to im¬ 
prove performance at the expense of 
goal-scheduling fairness. A goal is 
spawned close to the front of the queue 
rather than the back. Therefore, the GC 
is more likely to contain recently 
spawned goals and capture locality of 
communication. 

Goal-management implementation 
complexity. Since the architectural sup¬ 
port for goal management described in 
this section is a paper design, and has 
not been implemented in VLSI, we brief¬ 
ly discuss the cost of implementation. A 
more detailed cost/performance analy¬ 
sis is appropriate. We propose architec¬ 
tural support for goal management in 
the form of an overlapped GMU, a GC, 
and a port to GM. 


Systems development workload 


The systems development workload (SDW) consists of seven large FCP pro¬ 
grams, shown highlighted in Figure C. The FCP programs are used for the devel¬ 
opment of concurrent software systems. 

First, the Logix operating system, fully written in FCP, represents the basic ex¬ 
ecution and development environment. The FCP compiler, debugger, and pro¬ 
gram analyzer (Solver) are tools used for development and prototyping of new 
systems. Simulatorl and Simulator2 represent two simulators of the FCP proces¬ 
sor architecture described in the “FCP processor organization” section. Distribute 
is a simulator of a ring multiprocessor architecture for the distributed execution of 
FCP. 

All the programs are large, authentic applications and are currently in use. We 
weigh each application equally, even though they have different characteristics. 
The typical working session consists of developing a prototype system using the 
Logix environment, compiling FCP programs, debugging them, and analyzing 
their execution. 

An alternative workload that is under consideration consists of FCP programs 
for the specification of communication protocols as well as distributed and systol¬ 
ic algorithms. Figure C also shows this workload. 



Figure C. The current systems development workload contains seven pro¬ 
grams (highlighted). Three more are under considerations. 
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GMU requires a simple controller that 
moves goals between the GC and GM, 
and synchronizes execution with the RU 
using a single flag. In terms of hardware 
resources, the most costly component 
in the goal-management system is the 
GC, which may require a large on-chip 
area. If a single window consists of 10 
registers, the total on-chip area required 
for a large number of goal windows may 
be prohibitively high. However, as the 
performance analysis in the next sec¬ 
tion shows, even a small-sized GC sig¬ 
nificantly reduces program execution 
time. A GC with four windows has 40 
registers, which is within the scope of 
today’s commercially available proces¬ 
sors. 

The GC organization must also allow 
the concurrent access by the RU and 
GMU to disjoint sets of goal windows. 
While the RU accesses active and spawn 
windows, the GMU may overflow or 
underflow the GC, resulting in goal trans¬ 
fers to memory. This can be implement¬ 
ed using an additional register bus, which 
would further increase the size of the 
GC. Finally, the separate GM port will 
require an additional number of chip 
pins. 

Performance 

evaluation 

Performance measures. To evaluate 
the architectural support for goal-man¬ 
agement execution, we define the two 
following performance measures: 

(1) The average RU-GMU wait time 
per executed instruction, W , is a mea¬ 
sure of the time that RU waits for GMU. 
The wait time directly affects program 
execution time. The objective is to re¬ 
duce this overhead. 

(2) For a given system workload, the 
GMU (RU) utilization, U gmu (t/J, de¬ 
termines the fraction of time spent per¬ 
forming goal management (reduction) 
relative to the program execution time. 
Together, the utilization factors are a 
measure of the workload balance. 

System organization and workload. 

Figure 6 presents the RU-GMU system 
organization used to define the perfor¬ 
mance model. The figure shows the func¬ 
tional units RU and GMU, the GC, and 
the GM. 

The RU executes a RISC instruction 



set, whereas the GMU executes goal- 
management instructions. Both instruc¬ 
tion streams are received from the IU. 
GMU instructions that execute only in 
the GC are modeled as GC hits, where¬ 
as those instructions that require access 
to the GM are considered a GC miss. 
The GC miss rate depends on the num¬ 
ber of windows N w , and the miss penalty 
depends on the GM bandwidth B and 
the width of the GM word L. The values 
of the program parameters used in the 
performance model depend on the sys¬ 
tem workload. 

Our systems development workload 
(SDW) consists of seven large applica¬ 
tions used during the development of 
parallel programming systems. (See the 
sidebar on p. 40.) 

Performance model. In the perfor¬ 
mance model, we make the following 
assumptions: 

(1) The average RU instruction exe¬ 
cution rate is t m = 1. That is, the RU 
executes one instruction each processor 
cycle. We do not take into account that 
the average execution time can be great¬ 
er than one due to misses in the data 
cache, branches in the processor pipe¬ 
line, etc. This assumption is reasonable 
since there are standard techniques that 
can be used to bring the execution rate 
close to one instruction per processor 
cycle. 

(2) The absolute execution time of a 
goal-management instruction that re¬ 
sults in a GC hit is =1. This is 
reasonable since goal-management in¬ 


structions that result in a GC hit require 
changing the goal status bits; this can be 
performed in a single cycle. However, 
since all goal-management instructions 
that result in a GC hit are completely 
overlapped with goal-reduction execu¬ 
tion, their effective execution time is 
= 0. In other words, goal-manage¬ 
ment instructions that result in a GC hit 
cannot contribute to the wait time. 

Average RU-GMU wait time. The av¬ 
erage RU-GMU wait time, W , is equal 
to the ratio of the total RU-GMU wait 
time W and the number of executed 
instructions N m . That is, 



To determine W, we consider the ex¬ 
ecution of two consecutive GMU in¬ 
structions (see Figure 7). Let d(i) de¬ 
note the elapsed time between two 
consecutive GMU instructions gmu, and 
gmu M , and t“'” u (i ) the absolute execu¬ 
tion time of GMU instruction i that 
results in a GC miss. If the duration of 
GMU instruction i is less than the dis¬ 
tance d(i), the wait time, w h is equal to 
0. However, if the duration is greater 
than the distance, a wait time greater 
than 0 is incurred. Thus, we express the 
wait time for the zth GMU instruction as 

te(0-<*(0) if <*(*>< <9 

0 otherwise 

( 2 ) 
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Table 1. GMU instruction execution times. 


pend, and activate instructions and their 
corresponding frequencies. That is, 


GMU Execution Time 

Description 

= r L x (S+3)/fil + 

Consecutive memory read/write 

[L/B~] + 

1 memory access 

1 

1 processor cycle 

t°‘" p = \Lx (S+2)/5l + 

Move goal to memory 

2(r(2/£)l) + 

Allocate hanger 

r Ni ar (3 x r L/si + r (2/s)i + 2)i 

Allocate suspension notes 

c = fiVL (3r(2/fi)l + fL/5l)l + 4 

Activate goals 


The total RU-GMU wait time is then 
represented as the sum over the total 
number of executed GMU instructions, 

N gmu , as 

W = '| m “(w,) (3) 

Note that t a g ™ u (i) is the absolute execu¬ 
tion time of the ith GMU instruction, 
and the wait time w, is its effective exe¬ 
cution time. Therefore, the average ef¬ 
fective execution time of GMU instruc¬ 
tions is also the average wait time per 
goal-management instruction. 

To determine the absolute execution 
time of goal-management instructions 
that result in a GC miss, let us assume 
that the GM word is L bytes wide, that 
the goal size is S words (4 bytes) and the 
GM bandwidth is B bytes per cycle. 
Table 1 shows the absolute execution 
times of goal-management instructions 
that result in a GC miss; the absolute 
execution times are determined by in¬ 
specting the goal-management algo¬ 
rithms. 

The absolute execution time of the 
halt and spawn instructions, t a ^ th , con¬ 
sists of moving the goal between the 
GM and the GC, as well as performing 
simple memory allocation. The goal- 
transfer time is proportional to the goal 
size S. The absolute execution time of 
the suspend instruction is linearly pro¬ 
portional to the number of variables, 
N s van the goal suspends on, in addition 
to the transfer of the suspended goal to 
GM. Similarly, the absolute execution 
time of the activate operation is linearly 
proportional to the number of goals 
activated, N c acl . 

Finally, to determine the average RU- 
GMU wait time according to expres¬ 
sions (1), (2), and (3), we obtain the 


distribution of distances between two 
consecutive goal-management instruc¬ 
tions for the system workload, D(d). 
The distribution is obtained separately 
for each of the four goal-management 
instructions and shows the distance be¬ 
tween goal-management instructions 
that results in a GC miss and the next 
goal-management instruction. 

RU and GMU utilizations. We define 
the RU utilization, U ru , as the ratio of 
the RU execution time, T ru , and the to¬ 
tal program execution time, T. 


GMU utilization U gmu is similarly de¬ 
fined as the ratio of the GMU execution 
time, T gmu , and the total program execu¬ 
tion time T. That is, 



where F gmu denotes the frequency of 
GMU instructions, and t gmu denotes the 
average absolute execution time of goal- 
management instructions. Note that the 
total number of executed instructions is 
N m , since GMU instructions are fetched 
and executed together with RU instruc¬ 
tions. The frequency of GMU instruc¬ 
tions is then expressed as 



The average absolute GMU instruc¬ 
tion execution time t gmu is expressed as 
the sum of the products of the average 
execution times for the halt, spawn, sus¬ 


tgmu = Fhaldhal, + ^sp + F S usplusp + FcoJac, 

(7) 

We can further represent the average 
execution time of a goal-management 
operation j, j e (halt, spawn, suspend, 
activate), in terms of the execution 
times of a GC hit t a,h , GC miss t a : m , as 
well as the frequency of GC hits , as 
follows: 

i j =F*tf+{l-Fr)t} m (8) 

According to the assumptions stated 
earlier, the absolute execution time of a 
GC hit is t a ' h =1; Table 1 shows the 
absolute execution times of a GC miss. 
The frequency of GC hits for the spawn 
and halt instructions is determined by 
the size of the GC. However, the miss 
rate for the suspend and activate oper¬ 
ations do not depend on the GC size. 
Since every suspension transfers a goal 
from the GC to the GM, the frequency 
of GC hits due to suspend is F gusp = 0. 
The frequency of GC hits due to acti¬ 
vate is the fraction of goal reductions 
that do not result in activating suspend¬ 
ed goals. 

Performance model parameters. Ta¬ 
ble 2 summarizes the parameters used 
in the performance model; they are 
grouped into program and system orga¬ 
nization parameters. Included in the 
program parameters are the number of 
executed RU instructions N m , the total 
number of the goal-management instruc¬ 
tions N gmu (and the separate counts for 
halt, spawn, suspend, and activate in¬ 
structions), the average size of a goal S , 
the average number of variables a goal 
suspends on the average number 
of goals activated N pcn and the distribu¬ 
tion of the goal-management instruc¬ 
tion distance D(d) for the four goal- 
management operations. Included in the 
system organization parameters are the 
number of goal windows N w , the GM 
bandwidth B, and memory width in 
bytes L. 

Performance analysis. Next, using the 
workload and model described above, 
we evaluate system performance. 

Average RU-GMU wait time. To ana¬ 
lytically determine the average RU- 
GMU wait time, we first determine the 
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Table 2. Performance model parameters. 


Program (Workload) Parameters 

N ru 

Number of RU instructions 

N^ 

Number of GMU instructions (total and separate) 

S 

Average goal size 

N‘ m 

Average number of variables per suspension 

N c aa 

Average number of activations per reduction 

D(d) 

Distribution of GMU instruction distances 

System Organization Parameters 

N w 

Number of goal windows in the goal cache 

B 

Goal-memory bandwidth 

L 

Goal-memory word size 


distribution of RU instruction distanc¬ 
es, D(d), between two consecutive GMU 
instructions, as shown in Figure 8 for 
the four goal-management instructions. 
Using these distributions and the abso¬ 
lute GMU instruction execution times 
shown in Table 1, we determine the RU 
wait time w (see Figure 9) for three 
different cases of GM bandwidth and 
two cases for the GC size. 

The GM bandwidth considered is B = 
2,4, and 8 bytes per cycle. The two GC 
sizes are a minimal cache that consists 
0 fJV w = 4 windows (active, spawn, ready, 
and free) and a GC that is large. A large 
GC enables all halt and spawn instruc¬ 
tions to always execute in the GC. We 
do not correlate the actual GC size and 
the captured locality of halt and spawn; 
we just examine the two extreme cases. 

The first bar (black Jutf Figure 9 shows 
the average wait time W { when the GMU 
and the GC are not used. In this case, 
the goal-management operations are 
implemented in software, using RU in¬ 
structions. 

The second bar (white) of Figure 9 
shows the average wait time W 2 when 
the goal-management operations exe¬ 
cute sequentially, using the same execu¬ 
tion times as if a minimal GC is used. 
The third and fourth bars (gray) repre¬ 
sent the average wait times when goal- 
management operations are overlapped 
using a minimal cache W,and a large 
cache W 4 . The only difference between 
the second and third bars is that the 
goal-management operations are over¬ 
lapped in the third. 

If the goal-management operations 
are implemented in software using RU 
instructions, the average wait time is 
Wj = 1. That is, half the time is spent 
performing goal management. Using the 


GC but not overlapping goal-manage¬ 
ment operations reduces the average 
wait time almost threefold for a memo¬ 
ry bandwidth of 2 bytes per cycle. That 
is, W t IW 2 = 2.96. The average wait time 
reduces further as the GM bandwidth 
increases. 

Overlapping goal-management exe¬ 
cution using the GC further reduces the 
average wait time. For the GM band¬ 
width of 2bytes per cycle, W 2 IW 3 = 2.75. 
Further reductions in the average wait 
time are obtained by increasing the GC 
size, but these changes are not signifi¬ 
cant. The overall reduction of the aver¬ 
age wait time, from the software imple¬ 
mentation to the overlapped execution 
using a GC, is equal to 8.14. 

The wait time is not reduced further 
by an increase of the GC size because of 
the goal suspensions, which do not ben¬ 
efit from the GC, since every suspended 
goal is moved to the GM. To reduce the 
corresponding wait time, it is necessary 


to reduce the goal-transfer time; this 
can be achieved, for example, by in¬ 
creasing the GM bandwidth. However, 
goal suspension also requires the allo¬ 
cation of suspension notes, which are 
then linked into suspension lists. This 
implies an inherent data dependency, 
so that increasing the memory band¬ 
width reduces goal-suspension time as 
long as it affects the goal-transfer time. 
Further increases in GM bandwidth are 
not useful. 

The GC size influences the average 
execution time of halt and spawn. How¬ 
ever, most of the halt and spawn in¬ 
structions are overlapped even with a 
minimum GC configuration of four goal 
windows. The difference between the 
minimum GC and a large GC becomes 
even less significant as the GM band¬ 
width increases, since the execution 
times of halt and spawn are further re¬ 
duced. Consequently, the wait time is 
mainly caused by the goal-suspension 



d 


Figure 8. Distance distribution of the four goal-manage¬ 
ment unit instructions. 


Figure 9 Average wait time, W. 
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Figure 10. Reduction unit and goal-management unit utilizations, U ru and U gmu . 


instruction. For the GM bandwidth of 2 
bytes per cycle, the reduction in the 
average wait time obtained by increas¬ 
ing the GC size is W } I W 4 = 1.8. From 
the results shown in Figure 9, a mini¬ 
mum GC size of four goal windows, 
together with a GM bandwidth of 4 
bytes per cycle, results in an average 
wait time of 3 percent. 

RU and GMU utilization. Figure 10a 
shows the RU utilization, which is al¬ 
ways over 88 percent. As the GC size or 
the GM bandwidth increases, U ru in¬ 
creases because the average execution 
times of the goal-management opera¬ 
tions are reduced; thus, the RU wait 
time is reduced. This is not the case for 
GMU utilization (see Figure 10b). As 
the average execution time of GMU 
instructions is reduced, so is GMU uti¬ 
lization. This is because the reduction 
of goal-instruction execution time is 
larger than the reduction of the result¬ 
ing wait time and thus larger than the 
reduction of the total program execu¬ 
tion time. 

For example, for the minimum GC 
size and a GM bandwidth of 4 bytes per 
cycle, the GMU utilization is U gmu = 20 
percent. This implies an imbalance of 
goal management and goal reduction 
leading to an underutilized GMU. A 
meaningful way to improve GMU utili¬ 
zation is to use GMU idle time to per¬ 
form additional low-priority computa¬ 
tions. For example, the GMU could 
perform incremental goal reordering in 
the goal queue according to locality of 
intergoal communication or according 
to goal priorities. Alternatively, if sev¬ 
eral RUs fit onto a single VLSI chip, 


then a single GMU can serve several 
RUs at the same time. 

Goal-management 
complexity and 
overlapped execution 

For the systems development work¬ 
load, we showed that using the GMU 
and the GC can double the performance 
of FCP program execution relative to 
an environment that does not have sup¬ 
port for goal management. Next, we 
consider alternative workloads that have 
different granularities of goal reduction 
and goal management. 

Granularity of goal reduction. We 

define the granularity of goal reduction 
as the average execution time of goal 
reduction per goal, T r . For a processor 
that executes one instruction per cycle, 
the granularity can be measured as the 
average number of executed instruc¬ 
tions per goal, N r . 

Compared to previously reported 
measurements, the SDW exhibits a high¬ 
er granularity of goal reduction because 
we use larger and more complex appli¬ 
cations. Table 3 shows the goal-reduc¬ 
tion granularity for each component 
program of the workload. The average 
is 256 instructions per goal reduction. 
The higher granularity resulted in a low 
frequency of goal-management opera¬ 
tions, F gmu ~ 4 percent. 

However, also note the high variance 
of goal-reduction granularities in the 
system workload. Programs that exhib¬ 
it a higher granularity are applications 


used as metainterpreters. For example, 
the debugger is used to debug the exe¬ 
cution of the FCP processor simulator 
written in FCP. It takes the simulator 
program as data and symbolically inter¬ 
prets its execution, resulting in high gran¬ 
ularities of 400 to 800 instructions. In 
the simulator programs, on the other 
hand, a goal reduction mainly consists 
of modifying the processor state for each 
fetched and executed instruction. This 
results in a low granularity of 20 to 40 
instructions. 

Granularity of goal management. We 

define the granularity of goal manage¬ 
ment, T gm , as the average execution time 
of goal-management operations during 
a goal reduction, measured as the num¬ 
ber of executed RISC instructions, N gm . 
The granularity of goal management is 
a function of several program and im¬ 
plementation-dependent parameters. 
For example, it depends on the average 
goal size, the number of variables a goal 
suspends on, and so forth. Table 3 shows 
the goal-management granularities for 
each application in the workload. 

Complexity of goal management. The 

complexity of goal management, C, is 
the ratio of goal-management granular¬ 
ity, T gm , and goal-reduction granularity, 
T;. 



When we refer to applications with high¬ 
er complexity of goal management, we 
mean that they have a higher execution 
time of goal management relative to 
goal reduction. Table 3 shows goal-man¬ 
agement complexity for each program 
in the workload. 

We next relate the goal-management 
complexity with the speedup obtained 
by reducing the effective execution time 
of goal management. The maximum 
speedup is obtained when the resulting 
effective execution time is zero, that is, 

S m o* = 1 + Z^l = 1 + c ( 10 ) 

Moreover, the realistic speedup ob¬ 
tained with the overlapped execution is 
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Table 3. Goal-reduction and goal-management granularities. 





FCP Benchmark Programs 



Compiler 

Simulatorl 

Simulator2 

Debugger 

Solver 

Distribute 

Logix 

N, 

25.0 

43.0 

20.0 

485.0 

728.0 

416.0 

78.0 

N gm 

38.0 

139.0 

98.0 

95.0 

56.0 

102.0 

66.0 

C 

1.5 

3.2 

5.0 

0.2 

0.1 

0.3 

0.8 

S 

2.5 

4.2 

6.0 

1.2 

1.1 

1.3 

1.8 


The achievable speedup is directly 
proportional to the goal-management 
complexity, and the actual speedup also 
depends on the residual wait time. This 
wait time depends on the frequency of 
goal-management operations and the 
complexity of goal suspensions. 

Table 3 shows the maximum speedup 
due to overlapped and efficient execu¬ 
tion of goal-management operations for 
the component programs of the work¬ 
load. For example, programs like Simu¬ 
lator spend more time performing goal 
management than goal reduction. If we 
consider granularities greater than 200 
as high and from 10 to 30 as low, we then 
partition the space of goal management 
and reduction granularities into the fol¬ 
lowing four regions (see Figure 11): 

• M-domain : Low goal-management 
and high goal-reduction granularities 
are characteristic of metainterpreters 
and other applications that interpret 
programs as data. 

• A-domain: Low goal-management 
and goal-reduction granularities are 
typical of small applications, often 
used for comparative benchmarking 
such as the list Append program. These 
applications perform very little goal 
management and the reduction granu¬ 
larity is approximately 20 RISC opera¬ 
tions. 

•S-domain: High goal-management 
and goal-reduction granularity is ob¬ 
served in the systems development work¬ 
load. 

• C-domairv. High goal-management 
and low goal-reduction granularity is 
characteristic of applications that ex¬ 
plicitly model the intergoal communi¬ 
cation and synchronization. For exam¬ 
ple, the FCP programming stereotypes 
used by Taylor, Shapiro, and Shapiro 12 
explicitly model intergoal-communica- 
tion protocols and thus perform fre¬ 
quent goal-management operations, 
whereas goal reduction is simple. 


Figure 11 also shows the plane that 
delimits higher complexity domains (C 
>1) from lower complexities (C < 1), 
and the average program execution time 
of the system workload, which consists 
of the goal-reduction and -management 
effective execution times, T, and T gm . 
When goal-management instructions are 
implemented in software, we showed 
that T r ~ T gm . Therefore, the complexity 
of goal management which corresponds 
to the S-domain is C ~ 1. In this case, 
goal-management operations were con¬ 
sidered a bottleneck, which motivated 
special-purpose support using GMU. 
The maximum possible speedup due to 
overlapped execution of goal man¬ 
agement, S max , is achieved when the goal- 
management operations are complete¬ 
ly overlapped. For the systems develop¬ 
ment workload, the maximum speedup 
is Sf ax =2. We showed that the wait 
time due to overlapped execution is 3 
percent of T r . Therefore, S' s ~ S J““ = 2. 


Table 4. Goal-management activity. 


We label the goal-reduction and goal- 
management times in the C-domain as 
T' and T ' m , respectively. For this appli¬ 
cation domain T' < T r , so for the corre¬ 
sponding goal-management complexi¬ 
ties C c > C s . Therefore, the maximum 
possible speedup due to overlapped goal 
management using the GMU in the C- 
domain is >5"“. 

We considered simple distributed al¬ 
gorithms such as the Lord of the Rings, 
which computes the extreme value of 
nodes connected in a unidirectional cir¬ 
cle using (O (N log N) messages. A goal 
reduction here consists of executing sev¬ 
eral instructions that check whether the 
input channel has a message. If it has, a 
reply message is sent on the output chan¬ 
nel. If the message has not arrived, the 
goal reduction suspends. 

To indicate the degree of goal-man¬ 
agement activity in this sample program, 
we show in Table 4 the total number of 
goals created, terminated, suspended, 


Figure 11. Goal- 
management com¬ 
plexity domains. 


Lord of the Rings, N = 200 

Creations Terminations 

Suspensions 

Activations 

Reductions 

7,342 

7,342 

6,779 

6,779 

22,745 



August 1992 


45 




















and activated, as well as the total num¬ 
ber of goal reductions, for a ring of 
N = 200. The average goal-reduction 
granularity is counted as 30 hand- 
compiled RISC instructions executed 
by the RU. For the case where each 
goal suspension always suspends on only 
one variable (the receive channel), the 
goal-management granularity corre¬ 
sponds to 150 RU instructions. Thus, 
the goal-management complexity is C = 
5, resulting in a maximum speedup of 
S ma * = 6. 


W e have proposed special- 
purpose architectural sup¬ 
port as a way to reduce the 
goal-management execution time in Flat 
Concurrent Prolog. The architectural 
support consists of a dedicated goal- 
management unit that executes high- 
level goal-management operations 
concurrently with goal-reduction oper¬ 
ations. Moreover, the efficient execu¬ 
tion of goal-management instructions is 


enabled using a goaf cache that stores 
recently spawned goals. 

Operations such as goal-switching, 
spawning, and halting are efficiently 
performed by changing their status in 
the GC. More complex operations, such 
as goal suspension and activation, are 
decoupled from goal reduction by using 
two suspension tables and activation 
queues. For the systems development 
workload, which consists of large FCP 
programs, we show, using an analytic 
performance model, that the overhead 
of software-implemented goal manage¬ 
ment is 50 percent of the program exe¬ 
cution time. This is reduced to 3 percent 
using the GMU and the GC, thus result¬ 
ing in a speedup of almost 2. 

We also generalized our results for 
other workloads that exhibit different 
goal-management complexities. In par¬ 
ticular, FCP programs that explicitly 
model intergoal communication and 
synchronization exhibit higher goal- 
management granularity than goal-re¬ 
duction granularity, resulting in higher 
potential speedups. ■ 
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Flexible Text Display 
with Lector 


Darrell R. Raymond, University of Waterloo 


Lector provides flexible 
text interaction for Xll 
applications. It handles 
descriptively marked- 
up text and acts as a 
text previewer, 
database browser, 
code prettyprinter, or 
menu utility. 


D | espite increasing interest in iconic interfaces and visual programming 
f methods, text is ubiquitous in the computer environment and its impor- 
I tance is undiminished. Source code, documentation, electronic mail, 
electronic bulletin boards, and on-line manuals are clear cases of text-rich appli¬ 
cations. Text is also important in small, frequent tasks such as on-line help, menus, 
diagnostic messages, and the output of operating system utilities. The pervasive¬ 
ness of text in computer work argues for powerful, general methods for text display 
and interaction. 

Text-rich systems have tended to cling to long-established application con¬ 
straints rather than evolving toward more general solutions. Source code, for 
instance, is still generally handled with character-based text editors, despite 
extensive research into structure-based editors and code prettyprinters. On-line 
documentation tends to be supported by batch-oriented typesetting programs and 
associated previewers. Program diagnostics and usage messages are hardwired in 
code and displayed by dumping them into terminal programs or files. 

Good reasons exist for taking different approaches to text, but the result has 
been an overall lack of consistency in output quality and interaction. Standard text 
editors, for example, permit interactive editing, whereas compiled-in code and the 
output of operating system commands do not. 1 Typesetting programs and pre¬ 
viewers provide an almost infinite variety of styles, while editors are usually 
restricted to a single font and style of display. Both editors and typesetters are too 
slow or bulky for use in small or dynamic applications such as error messages and 
menus. Systems such as electronic mail and bulletin boards tend to converge on the 
lowest level of device capability, so they can be used over a wide range of output 
devices. Hardwired text is very efficient but typically provides minimal formatting 
capability. 

The lack of consistency in approaches makes it difficult to raise the overall 
quality of text display in the computer environment. Since text display is usually 
not the primary activity of applications, and since general solutions are often not 
available, most programmers quickly settle for familiar solutions. Thus, to signif¬ 
icantly affect overall text quality, we must provide both the software and the 
philosophy that encourages better text handling. Programmers should have simple 
and effective means for high-quality text interaction and should be convinced that 
the advantages of improved display quality are worth the effort. 

At the University of Waterloo, we have been exploring the unification of a range 
of text management situations with Lector, an Xll application for flexible text 
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comma ('kmna). PI. commas (formerly -aes); as 
L. or Gr., coinmata (’kDmata). [a. L. comma, Gr. 
Ko^a stamp, piece cut off, short clause, 
etc.: — *Kow-pa, f. kott - root of kotttciv to strike, 
cut.] 

1. In Greek Rhet. and Prosody. A phrase or 
group of words less than a colon (q.v.). Hence, 
•(•A short member of a sentence or period. 

1586 A. Dav Eng. Secretary II. (1625) 85 The last word of 
a comma, or member of a sentence. 1607 Shaks. 7 1 man 1. 1. 
48 Poet. No leucll'd malice Infects one comma in the course 
I hold. 1609 R. Barnard Faithf. Sheph. (1621) 87 In words, 
phrases, continues, and periods. 1711 Addison Sped. No. 
105 If o He has only rectify’d a Greek Particle, or laid out a 
whole sentence in proper Commas. 1713 Bentley Rem. 
Free-Dunking Wks. (ed. Dyce) III. 328 The next Comma of 
the passage is inexurabile /alum. 

fb. A clause or short member of a treatise or 
argument. Obs. 

1649 Jlii. Tayi.or Gt. Exemp. 11. 100 This being the 
hardest comma in the whole Discipline of Jesus is tortihed 
with a double blessednesse. 1652 L. S. People’s Liberty 11. 3 
The main argument.. is bottomed upon part of the 7th 
comma of the 4. Chapter of Gen. 1671 L. Addison IP. 
Barbary 171 (T.) In the Morcsco catalogue of crimes, 
adultery and fornication are found in the first comma. 

2. A punctuation-mark [now,] used to separate 
the smallest members of a sentence. Also used 
to separate figures and symbols in arithmetic, 
chemical formula;, etc. 

'The comparative length of the xoppa and ku\ov have given 
origin to our terms of punctuation indicating the close of 
such shorter or longer clauses respectively, just as our 
‘period’, or full-stop, marks the end of a nepio&os . J. E. 
Sandys on Cicero’s Orator §211. 

The function of the comma is to make clear the 
grammatical structure, and hence the sense, of the passage; 
one of the means by which this is effected in actual speech is 
a short pause; hence the comma is often inaccurately said to 
be merely the mark of such a pause; see quots. under b. 
no Palsgh. 39 With suche [point] as the Latins call 
' 3 ■ tade (:), or virgula thus made (,).] .599 R- B. 

iv. Hen. VII, To Printer, Keepe points, and 
•iodes. 1661 S. Partridge Double Scale 
Proport.’ 17 the Numerator is first expressed, and after it the 
Denominator right on in the line, with a comma betwixt, as 
..75,100. 1668 Wilkins Real Char. 393 The Characters 
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comma (krana). PI. commas (formerly -aes); 
as L. or Gr„ commata (komata). [a. L. comma, 

Gr. Koppa stamp, piece cut off, short clause, 
etc.:-*Kon-u<x, f. Kon- root of rameivto strike, 
cut.] 

1. In Greek Rhet. and Prosody. A phrase or 
group of words less than a colon (q.v.). Hence, 
A short member of a sentence or period. 

1586 A. DAY Eng. Secretary II. (1625) 85 The last 
word of a comma, or member of a sentence. 1607 
SHAKS. Timon i. i. 46 Poet. No leuell’d malice Infects 
one comma in the course I hold. 1609 R. Barnard 
Faithf. Sheph. (1621) 87 In words, phrases, commaes, 
and periods. 1711 Addison Spect. No. 105 p. 9 He 
has only rectify’d a Greek Particle, or laid out a whole 
sentence in proper Commas. 1713 BENTLEY Pem. 
Free-thinking Wks. (ed. Dyce) III. 328 The next Comma 
of the passage is inexorabiie fatum. 

\ b. A clause or short member of a treatise or 
argument. Obs. 

1649 JER. TAYLOR Gt. Exemp. II. 100 This being the 
hardest comma in the whole Discipline of Jesus is 
fortified with a double blessednesse. 1652 L. S. 
People’s Liberty ii. 3 The main argument .is bottomed 
upon part of the 7th comma of the 4. Chapter of Gen. 
1671 L. ADDISON W. Barbary 171 (T.) In the Moresco 
catalogue of crimes, adultery and fornication are found 
in the first comma. 

2. A punctuation-mark [now,] used to 
separate the smallest members of a sentence. 
Also used to separate figures and symbols in 
arithmetic, chemical formulae, etc. 

‘The comparative length of the komijo and wuXov 
have given origin to our terms of punctuation 
indicating the close of such shorter or longer clauses 
respectively, just as our‘period’, or full-stop, marks 
the end of a nepioSoc’. J. E. Sandys on Cicero’s 
Oratory 211. 

The function of the comma is to make clear the 
grammatical structure, and hence the sense, of the 


Figure 1. Entry for the word comma from the Oxford English Dictionary: (left) from printed page, (right) in Lector 
window. 


interaction. We originally devised the 
program as a simple, rapid formatter 
for the display of on-line text databases. 
As our experience with Lector devel¬ 
oped, we discovered that it exhibited 
useful capabilities for a wide range of 
text applications. While Lector itself is 
probably not an optimal solution, it has 
interesting implications for generaliz¬ 
ing text interaction, which the remain¬ 
der of this article describes. 

A tour of Lector 

The program takes as input an in¬ 
stance of text and a style specification; 
as output it displays the formatted text 
in a single XI1 window. Figure 1 shows 


the entry for the word comma in the 
Oxford English Dictionary, reproduced 
both from the printed page and as seen 
in a Lector window. The text contains 
bold, italic, and roman typefaces, as well 
as characters from the Greek and Inter¬ 
national Phonetic Alphabet, presented 
in two point sizes. Lector reproduces 
most of these elements quite legibly, 
though it was not intended to provide 
an exact simulation of the printed page. 
Some notable differences are the use of 
a sans serif font, the lack of right justifi¬ 
cation, and lack of accents on Greek 
characters. 

In addition to simulating the printed 
text, the program supports multiple al¬ 
ternative styles, four of which are shown 
in Figure 2. These are (clockwise) a 


skeleton style, a quotations style, a quo¬ 
tation-suppressing style, and a view of 
all text and tags, showing the typeset¬ 
ting actions applied to the tags that cause 
actions. This latter view can be used to 
debug the style specification itself. Fig¬ 
ure 2 also shows Lector’s menus, with 
the menu pane containing the list of 
styles visible. 

Note that the windows in Figure 2 
have different sizes and use multiple 
columns. Lector formats text to fill the 
user’s chosen window size, responding 
dynamically to window resizing rather 
than filling a predetermined page. Page 
breaks, line breaks, and column size are 
determined interactively in Lector; type¬ 
setting previewers operate with prede¬ 
termined page and line breaks. 
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Figure 2. Styles for viewing comma. 


The input text is marked with struc¬ 
tural tags that are bound to typesetting 
actions through a style-specification file. 


The tags are compatible with the Stan¬ 
dard Generalized Mark-up Language, 
or SGML. 2 Figure 3 shows the text of 


<ExHGxHLxLF>comma</LFxSF>comma</SFxMF>comma</MFx/HLxMPR> 
k<i>o&hook.</i>&sd.ma&breve.</MPRxIPRxIPH>&sm.k&rfa.m&schwa.< 
/IPHx/ IPR>. </HGxVL>Pl. <VF>commas</VF> (formerly <VF>~aes</VF 
>) ; as L. orGr., <VF>commata</VFxMPR>k<i>o&hook. </i>&sd.ma&br 
eve. ta&breve. </MPRxIPRxIPH>&sm. k&rfa.m&schwa. t&schwa. < / IPHx/ 
IPR>. </VLxET>a. <L>L.</LxCF>comma</CF>,<L>Gr.</Lxgk>ko&acu. 
mma</gk>stamp, piece cut off, short clause, etc.:-* <gk>ko&acu. 
p-ma</gk>, f. <gk>kop-</gk>root of <gk>ko&acu.ptein</gk>to stri 
ke, cut .</ETxpxS4x#>l</#xS6xDEF>In <CF>Greek</CFxLB>Rhet. 
</LB>and <LB>Prosody</LB>: A phrase or group of words less than 
a colon (q.v.). Hence, &dag.A short member of a sentence or pe 
riod. </px/DEFxQPxEQxQxD>1586</DxA>A. Day</AxW>Eng. Secre 
tary</W> <sc>ii. </sc>(1625) 85 <T>The last word of a comma, or 
member of a sentence. </Tx/Qx/EQxQxD>1607</DxA>Shaks . </AxW 
>Timon</Wxsc>i . </sc>i. 48 <W>Poet .</WxT>No leuell' d malice I 
nfects one comma in the course I hold. </T> 


the entry for comma as it was tagged at 
the University of Waterloo. The struc¬ 
tural tags may be purely logical (an 
example of so-called “de¬ 
scriptive” markup such as 
the <Q> tag for “quotes” in 
Figure 3), or they may be 
tightly bound to typesetting 
semantics (an example of so- 
called “procedural” mark¬ 
up such as the <i> tag for 
“italic” in Figure 3). All that 
is required is that tags be 
uniquely distinguished from 
the remainder of the text. 


Figure 3. Tagged text 
for comma. 
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The style-specification file contains 
definitions of fonts and styles. A small 
part of the style-specification file for 
the Oxford English Dictionary is shown 
in Figure 4. Each font is given several 


symbolic labels to.be used in the re¬ 
mainder of the specification. Each style 
consists of a starting format, a set of 
tags, and a set of typesetting actions to 
be taken upon encountering the tags. A 


relatively small set of typesetting actions 
is supported, including the capability to 
change font, display a fixed string of text, 
vary indentation levels, and change ver¬ 
tical or horizontal spacing. 


# Font definitions 
<Font> 

<Name>-oed-helvetica-medium-r-scaps—12-*</Name> 

<Family>Helvetica</FamilyxType>Small Caps</TypexSize>12</Size> 
</Font> 

<Font> 

<Name>-oed-helvetica-medium-r-normal—12-*</Name> 
<Family>Helvetica</FamilyxType>Roman</TypexSize>12</Size> 
</Font> 

# Standard style 
<Spec> 

# Startup values 
<Name>Standard</Name> 

<Family>Helvetica</FamilyxType>Roman</TypexSize>14</Size> 
<PrText>on</PrTextxTabs>3 6 9 12 15 18 21 24 27 30</Tabs> 

# Tag definitions 

<TagxNamexE></NamexString> </Stringx/Tag> 
cTagxNamex /Ex /NamexLineBreak>on< /LineBreakx /Tag> 
<TagxNamexHLx/NamexType>Bold</TypexSize>14</Sizex/Tag> 
<TagxNamexIPRx/NamexString> (</Stringx/Tag> 

<TagxName>< / IPRx /NamexStr ing>) < / St r ingx /Tag> 

<TagxNamexQx/NamexSize>12</Sizex/Tag> 

<TagxNamexDx/NamexType>Bold</Typex/Tag> 

<TagxNamex/Dx /NamexType>Roman< /Typex / Tag> 
<TagxName>&Ae.</NamexString>&198 .</Stringx/Tag> 
<TagxName>&Beta.</NamexString>&66 .</Stringx/Tag> 


</Spec> 

# No Quotes style 
<Spec> 

# Startup values 
<Name>No Quotes</Name> 

<Family>Helvetica</Family><Type>Roman</Type><Size>14</Size> 
<Tabs>3 6 9 12 15 18 21 24 27 30</Tabs> 


</Spec> 


Figure 4. Style-specification file for the Oxford English Dictionary. 
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Multiple-process structuring 


Multiple-process structuring is a 
long-established technique that sup¬ 
ports rapid application development 
and software reuse. In a multiple- 
process environment, component 
programs are designed to be gener¬ 
al utilities of broad applicability and 
to share conventions about input 
and output. They are supported by a 
simple mechanism for process inter¬ 
connection. 1 Lector was designed to 
participate fully in such an environ¬ 
ment. 

The power of multiple-process 
structuring techniques is evident in 
the design of the cross-reference 
finder for the Oxford English Dictio¬ 
nary. In Figure A, the top left-hand 
window (the only one that is not an 
invocation of Lector) is used for en¬ 
tering search commands. Entries 
containing matches to string search- 

es are displayed in their entirety in Figure . he cross-re < 
the bottom left-hand window. As 
these entries are displayed, they are 
filtered by a small program that ex¬ 
tracts the cross-references from the entry. The extracted infor¬ 
mation is then tagged and sent to the middle window, where it 
appears as a menu of possible targets. Pointing at one of 
these cross-references results in a search for the target entry, 
which is then displayed in the rightmost window. In the figure, 
the entry for the word lecturer contains four cross-references, 
whose labels are displayed in the middle window. The user has 
just selected the cross-reference to Lector, and the target entry 
has been displayed in the target window. 

The process structure for the cross-reference application is 
shown in Figure B. The search window is used to locate a 
source entry of interest. The program Find_xref extracts the 
cross-references from the source entry and sends them to the 
menu. It also forwards the entry to the source entry display 
window. When a reference is selected from the menu, 

Find_xref is informed and calls Find_target to locate the target 
entry. This is done by using a second search engine. The re¬ 
sult is then shown in the target display. 

Developing the cross-reference application was greatly sim¬ 
plified by using multiple interconnected processes. The two fil¬ 
tering programs are no more than a few hundred lines of code, 
written in less than a week. Another week was spent develop¬ 
ing a simple shell to set up the process structure (standard 
Unix shells are not very useful for constructing nonlinear pro¬ 
cess structures). The implementation speed is only one bene¬ 
fit, however. Another is that the system is easily distributable. 

The search engines, filters, and display processes can reside 
on separate machines. Even the Lector processes need not 
run on the workstation used for display, since their connection 
to the X server is also based on multiple-process communica¬ 
tion. The application exhibits a high degree of modularity: Dis¬ 
play logic is isolated in Lector, search logic in the search en¬ 
gines, and cross-reference resolution logic in the two filter 
programs. As a result, the application can be easily modified 
and extended, even by programmers who do not have access 
to search-engine or Lector source code. 
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The display can be manipulated in 
several ways. The window itself can be 
arbitrarily resized or repositioned, caus¬ 
ing the text to be redisplayed using the 
newly defined width and height. Resiz¬ 
ing is also a convenient way to set the 
column width; the user sizes the window 
and presses a key to adjust the column 
size to the current window width. Mul¬ 
tiple columns in the new width can be 
obtained by resizing for a wider win¬ 
dow. The user can page forward and 
backward, or jump to the start or end of 
the text, by using the appropriate func¬ 
tion keys, mouse buttons, or menu se¬ 
lections. 

Lector has one other special naviga¬ 
tional feature of note: The user can 
point to a line of displayed text and 
cause the display to update so that the 
indicated line is at the top of the win¬ 
dow. When combined with a style such 
as the skeleton style of the word com¬ 
ma, this feature permits rapid naviga¬ 
tion. The user switches to a skeleton 
style, points to the desired subsection, 
and returns to a full-content style for 
detailed perusal. 

Software for text display must handle 
three basic structures. The first is the 
content itself, including its subdivisions 
and ordering, as well as the rules that 
distinguish content from embedded lay¬ 
out instructions or other codes. Second 
is the layout structure, which describes 
the basic display features of the soft¬ 
ware and how they can be combined 
(the programs that can be written). Third 
is the structure of potential interaction 
with the text, the role that the text soft¬ 
ware plays for the user and for other 
software packages. 

Text systems differ in their handling 
of the three basic structures. Hardwired 
text, for example, treats strings and char¬ 
acters as the basic subcomponents, sup¬ 
ports character-based layout codes, and 
has a single interaction possibility (it 
can be read). Typesetting systems, on 
the other hand, allow the user to define 
many types of subcomponents, such as 
tables and figures. They also have 
powerful layout functionality. Their in¬ 
teraction structure, however, is virtual¬ 
ly the same as for hardwired text. On¬ 
line text databases support a few types 
of subcomponents (documents, para¬ 
graphs, sentences, and words) and que¬ 
ry interaction, but typically have limit¬ 
ed layout capabilities. Lector is a unique 
combination of features for the three 
structures. 


Content 


Lector distinguishes between content 
and tags. Tags are any strings that con¬ 
form to a given syntax. Tags that are 
explicitly declared in the style specifica¬ 
tion are defined tags; strings that do not 
appear in the style specification, but 
which conform to the syntax, are unde¬ 
fined tags. All tags, defined or unde¬ 
fined, are independent; nesting and tag- 
pair relationships are not maintained. 
All strings that are not tags are content. 
Content fragments are displayed in the 
order of input and cannot be reordered. 

While most systems have a fixed syn¬ 
tax for defining markup, Lector permits 
the user to define (within limits) the 
syntax of the tags. In other systems, 
undefined markup is illegal; in Lector, 
undefined tags can cause some typeset¬ 
ting actions to occur. Since it is not 
possible to distinguish between instanc¬ 
es of undefined tags, any instance caus¬ 
es the same action. Most systems supply 
a limited amount of state maintenance, 
such as preserving and restoring a font. 
Lector does not preserve state. This 
strategy was chosen partly to ensure 
that Lector would robustly handle erro¬ 
neous text and partly to simplify for¬ 
matting under arbitrary navigation. 

In the present implementation, a tag 
syntax is a unique pair of start and end 
characters. SGML-like angle brackets 
are commonly used. The present imple¬ 
mentation allows styles to have more 
than one syntax, and styles need not 
share the same syntaxes. Varying tag 
syntaxes allows Lector to treat markup 
as a kind of content. 


Layout 

Layout rules are specified in the style- 
specification file. Users define a map¬ 
ping between markup syntax and se¬ 
mantics. The style specification describes 
the tag syntaxes, fonts, and styles used 
in a given invocation. The styles are 
intended to be simple to write; they are 
declarative in nature, with no control- 
flow statements, variables, procedures, 
or types. Each tag, font, and style spec¬ 
ification is independent of all others. A 
style specification is essentially a sym¬ 
bol table containing a mapping of tags 
to typesetting operations. 

An example of a style-specification 
file is shown in Figure 4. Style specifica¬ 


tions can be quite lengthy if many tags 
and styles are defined. One such file for 
the Oxford English Dictionary consists 
of nine styles, each defining nearly 200 
tags. 

The bulk of the style-specification file 
is a set of operations to be performed 
when specific tags are encountered. A 
small set of operations is supported, 
including 

• change of font (absolute or relative 
to the current font), 

• highlighting (currently implement¬ 
ed as reverse video), 

• change of indenting level, 

•“page break” (that is, stop filling 

the window), 

• printing of an arbitrary fixed string, 
and 

• vertical or horizontal motion. 

These few features are sufficient to 
display many types of running text. A 
very important additional feature is sup¬ 
pression, which discontinues or restarts 
the display of text at a given tag. Sup¬ 
pression permits the definition of styles 
that show outline views of the text. 

Many other text systems rely on so- 
called “procedural” markup, in which 
the layout actions are bound to system- 
defined tags. Lector lets the user define 
the mapping between layout actions and 
markup. Lector also provides only a 
small number of typesetting capabili¬ 
ties. The quality of its output is mainly 
due to the use of multiple proportional 
fonts. Full-fledged typesetting systems 
usually provide many more capabili¬ 
ties, such as headers and footers, right 
justification, kerning, and automatic 
hyphenation. Lector lacks these but pro¬ 
vides user-controllable suppression of 
text, an essential capability in interac¬ 
tive use and in the definition of multiple 
styles. Finally, in other systems, mark¬ 
up is usually suppressed by default. Lec¬ 
tor facilitates both the display of mark¬ 
up and the definition of a variety of 
display styles for that markup. 

Interaction 

Flexible interaction — Lector’s chief 
virtue — is achieved in several ways. 
First, its easy readjustment to the cur¬ 
rent window size encourages the user to 
choose a window size that suits the pur¬ 
pose. Second, rapid access to multiple 
styles and the use of repositioning make 
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it possible to navigate the text quickly, 
without excessive paging or using a scroll 
bar. Third, in addition to displaying text, 
Lector supports use of the text as an 
input medium. In menu mode, pointing 
to a line in the text causes the output of 
the file offset of that line. This informa¬ 
tion can be directed to other programs 
to perform some related task. In effect, 
the text has become a menu. Finally, the 
program can accept either new instanc¬ 
es of text or new positions on its input 
stream; thus, an existing invocation can 
be reused many times, and an existing 
instance of text can be redisplayed un¬ 
der program control. 

Most previewers require the whole 
text to be preprocessed into displayable 
format before they can begin display. 
Lector can begin formatting at arbi¬ 
trary points in an unprocessed text and 
read only as much of the text as is nec¬ 
essary to fill the current window. Most 
previewers simply display the text, lim¬ 
iting interaction to paging. Lector treats 
text as an interactive display and uses 
styles to support more powerful naviga¬ 
tion. Finally, where most previewers 
are restarted for each text instance, 
Lector is most often used as a persistent 
utility for many instances of text. This 


cuts down on process invocation costs 
and relieves the user of the need to 
manage new windows. 

Applications 

Lector’s capabilities suggest new ap¬ 
proaches to several traditional text-dis¬ 
play problems. 

On-line documentation. Lector is use¬ 
ful for the display of on-line documen¬ 
tation, since its multiple formats and 
index mode permit flexible navigation. 
Most existing on-line documentation 
either is not tagged with descriptive 
markup or uses tags whose syntax is 
more complicated than the present im¬ 
plementation can recognize. One such 
collection of text is the Unix man pages, 
which are tagged with the -man macros. 
Such texts can often be preprocessed 
with shell scripts to install more tracta¬ 
ble tags. 

Figure 5 shows the csh man page as 
seen via a combination of awk prepro¬ 
cessor and Lector. Three styles are 
shown: a skeleton style for use as an 
index, a standard view for reading, and 
a style showing the tags installed by the 



shell scripts. These invocations are pipe¬ 
lined so that pointing to the skeleton 
style results in the two other styles be¬ 
ing updated to the indicated position. 
This interconnection assists in search¬ 
ing long man pages, which are usually 
consulted simply to check a point of 
syntax. 

Converting the -man macros via a 
preprocessor may appear to be an un¬ 
necessary, complicating step. One ben¬ 
efit of this approach is that it separates 
the definition of the styles from the 
-man macro syntax so that the styles can 
be reused for other documents. Tex (of¬ 
ten printed as TgX) documents, for ex¬ 
ample, could be displayed using the same 
styles if a preprocessor was written to 
convert Tex macros to the tagging used 
by the style specification. Separating 
markup syntax from markup semantics 
enables style definition to be treated as 
an independent activity. 

Source code. On many computer sys¬ 
tems, the largest body of text is source 
code. Improved presentation helps us¬ 
ers comprehend this text. 3 Code pret- 
typrinters typically transduce the syn¬ 
tax of a specific programming language 
into a specific typesetting language. The 
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output is also usually confined to a sin¬ 
gle style, is not sensitive to window ge¬ 
ometry, cannot flexibly suppress code 
fragments, and does not employ the dis¬ 
play as an input medium. The examples 
shown in Figure 6 use Lector to support 
all these capabilities for previewing the 
C programming language. As in the case 
of on-line documentation, source code 
is preprocessed before being sent to 
Lector. Since C code is syntactically 
more complex than typesetting macros, 
a lex preprocessor is used to mark up 
the program. The preprocessor tags line 
breaks, reserved words, braces, com¬ 
ments, strings, and other simple syntac¬ 
tic features. 

The code displayed in Figure 6 is the 
main routine of the XI1 server, a rea¬ 
sonably nontrivial nested program. The 
C Grind style presents a traditional lay¬ 
out of the code. The Nesting style is a 
compressed view, showing only the 
major control-flow statements and their 
nesting. Multiple fonts and point sizes 
are used in the Nesting (Reduced) style, 
which shows the main control-flow state¬ 


ments in a large proportional font, with 
all other statements in the tiny nil font. 
This style gives the programmer a feel 
for both the nesting and the relative 
sizes of the code blocks. Finally, there 
are styles for displaying the comments 
and the string constants in the code. 

Lector supports both user-adaptable 
and language-independent prettyprint¬ 
ing of source code. 4 5 Because the style 
specification is provided by the user, 
styles are inherently adaptable. Lan¬ 
guage independence results from using 
installed markup rather than develop¬ 
ing styles based on a specific program¬ 
ming-language syntax. The tags are a 
kind of indirection table that maps lan¬ 
guage syntax to conceptual structures. 
As a result, the same styles can be used 
for viewing many languages. New lan¬ 
guages are accommodated simply by 
constructing the appropriate prepro¬ 
cessor. 

Lector’s simple model for text is an 
unexpected advantage in dealing with 
source code. Prettyprinters or editors 
that depend on correctly nested code 


have trouble with incorrectly nested 
programs, as is often the case with pro¬ 
grams under development. Because 
Lector’s specifications assume no nest¬ 
ing, they are more robust in the case of 
nesting errors. Some code-viewing tasks, 
however, expose limitations in Lector’s 
approach. Since tag definitions are stat¬ 
ic, the program cannot support high¬ 
lighting of individual variables or func¬ 
tion names dynamically specified during 
an interactive session. 6 

Menu utility. Lector can be used as a 
generic menu utility. To implement such 
a menu, users construct a tagged text 
file containing the menu options and 
take note of the file offsets of each 
option. The program presents the menu 
to the user, who selects an option by 
pointing to a line of text. The corre¬ 
sponding offset is output to the applica¬ 
tion program, which takes the desired 
action. 

Figure 7 shows Lector used as a menu 
utility for a structured text editor. The 
figure contains three invocations of the 
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Figure 7. Lector menus for structured editor. 


editor. Each one shows the editor win¬ 
dow and a Lector window, the latter 
displaying an abbreviated set of editor 
commands. The rightmost invocation 
shows the menu to the left of the editor; 
the bottom invocation shows the menu 
above the editor. The menus differ only 
in the number and size of columns dis¬ 
played. The leftmost invocation of the 
editor uses a different style for viewing 
the menu text. This style displays the 
editor formats that can be used for view¬ 
ing the text, all editor commands, and 
the help text associated with each com¬ 
mand. Not all of this information fits 
into the chosen window size, but the 
user can page, change styles, or use 
other navigational features to assist in 
scanning the menu file. 

The editor functions were originally 
accessed by a pop-up, multipane menu 
interface that was excessively slow and 
clumsy. The Lector menu has several 
advantages. First, it relieves the editor 


of handling menu interaction, simplify¬ 
ing editor design. Second, the menu can 
be configured by the user, who can 
choose the position, size, and orienta¬ 
tion of the menu; this is how the two 
rightmost invocations were arranged. 
Third, the content of the menu can be 
adjusted through style changes; suppres¬ 
sion can be used to hide menu options, 
help text, or other information to sim¬ 
plify the menu. Moreover, all these fea¬ 
tures can be configured without access 
to editor source code. 

The main disadvantage of Lector 
menus is that they require a process 
invocation, and hence are slower to start 
up and consume more resources than 
linked libraries do. On the other hand, 
the menus encourage modularity by 
isolating menu activity from the rest of 
the application. In addition, the menus 
exhibit several novel and desirable 
properties. They support multiple styles, 
runtime layout arrangement, embed¬ 


ded information, and flexible option 
suppression by means of style changes. 
The built-in capabilities for scrolling, 
paging, and multiple columns enable 
Lector to easily accommodate large 
menus. 

Discussion 

Lector embodies a four-part philoso¬ 
phy of text display and interaction. 

•Modularity: Lector is useful for 
building weakly coupled text applica¬ 
tions constructed of reusable modules. 
Such systems can be quickly prototyped 
and are easily modified. Weak coupling 
tends to concentrate display-specific 
activity in Lector and semantic opera¬ 
tions in the application itself. Lector is 
intended to do only text display and 
interaction well; other modules are as¬ 
signed to handle other activities. Lector 
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Flexible display of graphics 


The advantages of multiple styles, multiple windows, and the 
use of the display as a menu need not be restricted to text. Giv¬ 
en a font with appropriate iconic elements, Lector can support 
some interesting graphical interfaces as well. 

Figure C shows several views of the chess game played be¬ 
tween the programs Phoenix and Deep Thought at the 20th an¬ 
nual ACM North American Computer Chess Championship. 1 
Each view in the figure is an invocation of Lector, including the 
displays of the game board. A simple program was written to 
convert standard chess notation to a tagged text description of 
the board at each state of the game. That file is the source of 
each view shown in Figure C. The text style shows the full con¬ 
tent of the tagged text file. The notation style uses suppression 
to show only the individual moves, while the annotation style 
suppresses all but the annotations. The board styles result from 
mapping the board descriptions to appropriate glyphs in a 
chess font; shown are a complete board view and a view of 
only the knights and bishops. Multiple styles give the chess 
player many ways to study the game. 

Navigation through the game is assisted by the interconnec¬ 
tion of windows. The player can page backward or forward in a 
board view, which shows the next or previous move. Paging in 
the notation or annotation view permits jumping several moves 
at a time. Pointing to a specific move or annotation results in 
positioning the board views at that point in the game. 

The chess application is designed for use with a game log 
but could easily mediate a game in progress. Simple filters 
could be written to convert move notation to board descriptions, 
and to convert user input to move notation. Flagging of invalid 
moves and records of captured pieces can be provided by ex¬ 
tending the filters to embed appropriately marked-up informa¬ 
tion in the text and devising a style to display the feedback. 
Captured pieces, for example, could be presented by showing 
their icons or by displaying a bar chart showing the total value 
captured. 

Advanced text-display systems provide interesting insights 
into new types of flexibility for graphical user interfaces. In most 
such systems, graphical objects such as buttons, sliders, check 
boxes, and scroll bars are hardwired into a program. User con¬ 
figurability, when it is provided, is often tediously specified by 


means of a default file. An alternative approach, based on flexi¬ 
ble text display, is to specify a graphical interface or control 
panel with a text file that is mapped to appropriate iconic fonts, 
as in the chess example. By treating graphical interfaces as a 
kind of text, we gain a number of features not found in current 
direct-manipulation interfaces. Such a system supports 

• the display of very large control panels (accessed by means of 
paging or window resizing), 

• the selective display of icons and controls (by means of 
suppression), 

» a choice of panel layouts (by means of multiple styles), and 

• user-selectabie icons (by means of font changes). 

Moreover, each of these capabilities is supported exactly as it 
is in the case of text display, making it easier for users to trans¬ 
fer their abilities from one task to another. 

Management of graphical interfaces as a kind of text has im¬ 
portant implications for system decomposition. Instead of con¬ 
structing a program to manage a panel of buttons and sliders, 
one constructs a program to manage a “text" that describes the 
logical structure of that panel. This text is essentially a display- 
independent specification of an iconic interface. Instead of com¬ 
piling fixed rules about panel layout into a program, one con¬ 
structs a style specification that describes a number of possible 
layouts, subject to such display limitations as window geometry. 
This style specification is essentially an application-independent 
specification of layouts for a class of related interfaces. By fo¬ 
cusing on these two interfaces, we take another step toward the 
interchangeability of text and interface objects. 2 
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also modularizes display by separating 
style from content. 

• Efficiency: Fast, efficient text dis¬ 
play was a basic design goal. To this end, 
a minimal set of typesetting features 
was supported. Furthermore, conserva¬ 
tive memory policies were employed 
that lead to processing documents “on 
the fly” rather than preprocessing them. 
Additional efficiency is gained by call¬ 
ing XI1 directly through the basic li¬ 
brary Xlib, bypassing the use of a tool¬ 
kit. As a result, the executable binary is 
very small (a current Sparc version is 68 
Kbytes) and fast — especially useful 
properties in environments without 


shared libraries or where processing 
capability is at a minimum. Lector can 
be used on low-end X terminals with 
minimal memory. The capability to re¬ 
use an invocation for a new document 
adds extra savings on process start-up 
time, memory management, and most 
importantly, user effort in window man¬ 
agement. 

• Interactivity: The program treats 
text as a pliable medium that is useful 
for input and output. This necessitated 
layout policies that are responsive to 
window geometry, rather than to pre¬ 
determined page sizes. It also encour¬ 
aged the development of suppression 


and other style features to expand or 
contract the view of the text. In all cas¬ 
es, pointing at a text display has a de¬ 
fined result, which can be used to make 
the text an index to itself or to an appli¬ 
cation’s operations. The capability to 
work well with other modules is anoth¬ 
er important form of interactivity. 

• Flexibility: Lector tries to address as 
many text display problems as possible, 
including on-line documentation, schol¬ 
arly texts, system utilities, and code 
management. A wide range of applica¬ 
tions enforces simple but broadly appli¬ 
cable approaches to specifying, display¬ 
ing, and interacting with text. Flexibility 
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is greatly enhanced by modularity, effi¬ 
ciency, and interactivity, but it is also a 
design constraint. Its main effect is to 
temper the tendency to add applica¬ 
tion-specific features to the program. 

Many current text-management 
systems attempt to incorporate modu¬ 
larity, efficiency, interactivity, and flex¬ 
ibility. Object-oriented systems encour¬ 
age reusable, modular text-processing 
facilities. 7 Structured editors provide 
text manipulation based on abstract 
levels of structure. 8 Advanced typeset¬ 
ting systems increase the quality and 
variety of text layout. Text database 


software promotes the notion of the 
text itself as a modular entity that can 
be retrieved and displayed in a variety 
of ways. 9 

Lector’s approach differs from these 
other systems in two major ways. It is 
weakly coupled to applications and uses 
process decomposition for rapid devel¬ 
opment. The primary advantage of close¬ 
ly coupled applications is efficiency. 
Their primary disadvantage is their 
monolithic construction and lack of in¬ 
dependence from the underlying envi¬ 
ronment. Smalltalk and InterLisp pro¬ 
grammers sometimes complain that 
applications developed in integrated en¬ 


vironments are not easily portable out¬ 
side the environment. 10 Weakly coupled 
Lector-based applications, on the other 
hand, are highly portable. Since process 
communication is employed as the cou¬ 
pling interface, these applications are 
also easily distributed across worksta¬ 
tions and file servers. 

The second difference is that Lector 
treats text and menus as views of a sin¬ 
gle entity. Especially in object-oriented 
hierarchies, graphical and textual dis¬ 
play are distinctly different operations 
or objects. Menus are traditionally con¬ 
sidered graphical control or system ob¬ 
jects, while texts are data or user ob- 
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jects. Lector’s textlike menus and menu¬ 
like text show that this decomposition 
is not necessarily appropriate. Treating 
menus and text as interchangeable ob¬ 
jects provides the advantages of inter¬ 
activity for text and flexible layout for 
menus. 

Lector’s philosophy and implemen¬ 
tation could benefit from further work. 
The style-specification language is most 
in need of redesign, having evolved in 
an ad hoc fashion. The language capa¬ 
bilities should be enhanced to handle 
more types of text and formatting. 
Some thought should also be given to 
reducing the difficulty of creating styles. 
This has often turned out to be a non¬ 
trivial task, especially when many styles 
are defined for a complex document. If 
style creation becomes an important 
form of programming. Lector should 
support it with a more carefully con¬ 
structed language. 

Lector’s interaction capabilities are 
still too limited, particularly in provid¬ 
ing feedback about user pointing activ¬ 
ity. Many text-rich applications such as 
electronic mail and electronic bulletin 
boards require better input than Lector 
can provide. For such applications, weak 
coupling can lead to a clumsy design. 
Yet it seems worthwhile to provide 
multiple styles of news and mail, or to 
use these styles as indexes into a data¬ 
base. Similarly, we saw that the separa¬ 
tion of style from markup was a stum¬ 
bling block in displaying specific 
identifiers in code previewers, although 
it is otherwise a natural method for 
defining multiple styles. 

Much of Lector’s design emerged 
through juggling the trade-off between 
performance and generality. It is im¬ 
portant to keep this trade-off in mind as 
improvements are considered. Adding 
right justification of text, for example, 
would provide a neater appearance to 
some output. Its contribution to read¬ 
ability is questionable, however, and its 
execution cost is relatively high, espe¬ 
cially if one attempts to avoid rivers of 
white space or to provide good hyphen¬ 
ation. Another example of a problem¬ 
atic enhancement is the display of ta¬ 
bles. Tables can be quite informative, 
but they are also sensitive to some style 
changes. 11 The effect of table layout must 
also be considered in the light of Lec¬ 
tor’s capability to extend into display 
tasks not typically encountered by text 
previewers. For instance, how should 
table layout be handled in the face of 


frequently changing.window geometry? 
What sorts of table facilities would prove 
useful in laying out iconic displays? 
While identifying the most flexible so¬ 
lution is a difficult task, it is ultimately 
worthwhile if the goal is to unify a wide 
range of text-based applications. 


L ector was created to support a 
specific text application. As we 
developed an appreciation of 
the general need for powerful text dis¬ 
play and interaction, the program ma¬ 
tured into a module useful in a variety 
of applications. Lector exploits the use 
of descriptive markup for structuring 
text and shows the potential advantages 
of this technique for menus, interactive 
displays, database browsers, and code 
prettyprinters. Focusing our attention 
on general text display and interaction 
problems has provided us with unex¬ 
pected insights into a wide variety of 
application problems. ■ 


Acknowledgments 

Lector’s design and implementation were 
influenced by the comments and suggestions 
of all members of the Centre for the New 
Oxford English Dictionary. My particular 
thanks go to Heather Fawcett, who suggest¬ 
ed interconnecting multiple Lectors; to Gord 
Broom, who built several of the applications; 
and to Frank Tompa, for his continual stream 
of ideas and comments on many early drafts. 
Extensive criticism by the anonymous refer¬ 
ees also significantly improved this article. 

Financial support was provided by the 
Natural Sciences and Engineering Research 
Council of Canada through the University- 
Industry Program under Grant No. 0039063. 


References 


1. C. W. Fraser and B. Krishnamurthy, “Live 
Text,” Software — Practice and Experi¬ 
ence, Vol. 20, No. 8, Aug. 1990, pp. 851- 
858. 


2. Information Processing — Text and Of¬ 
fice Systems — Standard Generalized 
Markup Language (SGML), ISO 8879- 
1986, Int’l Organization for Standardiza¬ 
tion, 1986. 

3. R. Baecker and A. Marcus, “Design Prin¬ 
ciples for the Enhanced Presentation of 
Computer Program Source Text,” Proc. 
CHI 86 Conf. Human Factors in Comput¬ 
ing Systems, ACM, New York, 1986, pp. 
51-58. 


4. G. Blaschek and J. Sametinger, “User- 
Adaptable Prettyprinting,” Software — 
Practice and Experience, Vol. 19, No. 7, 
July 1989, pp. 687-702. 

5. M.O. Jokinen, “A Language-Indepen¬ 
dent Prettyprinter,” Software — Prac¬ 
tice and Experience, Vol. 19, No. 9, Sept. 
1989, pp. 839-856. 

6. D.R. Raymond, “Reading Source Code,” 
IBM Canada Laboratory Tech. Report 
No. TR 74.070, IBM Canada, Toronto, 
Ontario, 1991. 

7. M.A. Linton, J.M. Vlissides, and P.R. 
Calder, “Composing User Interfaces with 
Interviews,” Computer, Vol. 22, No. 2, 
Feb. 1989, pp. 8-22. 

8. V. Quint and I. Vatton, “Grif: An Inter¬ 
active System for Structured Document 
Manipulation,” Proc. Int’l Conf. Text 
Processing and Document Manipulation, 
Cambridge Univ. Press, Cambridge, En¬ 
gland, 1986, pp. 200-213. 

9. D.E. Eganet al., “Formative Design Eval¬ 
uation of SuperBook,” ACM Trans. In¬ 
formation Systems, Vol. 7, No. 1, Jan. 
1989, pp. 30-57. 

10. “Panel: Confessions — What’s Wrong 
with Our Systems,” Proc. Hypertext 89, 
ACM, New York, 1989. 

11. R.J.Beach,“TabularTypography,"Proc. 
Int’l Conf. Text Processing and Docu¬ 
ment Manipulation, Cambridge Univ. 
Press, Cambridge, England, 1986, pp. 18- 
33. 



Darrell R. Raymond is a doctoral student in 
the Department of Computer Science at the 
University of Waterloo. His research inter¬ 
ests include conceptual data modeling, type¬ 
setting, menu-based systems, process struc¬ 
turing, and the study of notation. 

Raymond received a BSc degree in ap¬ 
plied mathematics from McMaster Universi¬ 
ty, Hamilton, Ontario, Canada, in 1981 and 
an MMath degree in computer science from 
the University of Waterloo in 1983. He is a 
member of the ACM. 


Readers may contact the author at the 
Department of Computer Science, Uni¬ 
versity of Waterloo, Waterloo, Ontario, 
Canada N2L 3G1, e-mail drraymon@ 
daisy.waterloo.edu. 


60 


COMPUTER 









Demonstrational 

Interfaces: 

A Step Beyond 
Direct Manipulation 


Brad A. Myers 

Carnegie Mellon University 


With demonstrational 
interfaces, the user 
applies direct- 
manipulation 
techniques to 
abstractions by 
operating on example 
values. Applications 
range from text editing 
to visualization. 


n his classic 1983 article, Ben Shneiderman introduced the concept of a 
“direct manipulation” interface, in which users point to objects on the 
JL sc t een and manipulate them using a mouse and keyboard. 1 With the advent 
of the Apple Macintosh in 1984, this style of interface became more popular and 
now is widely accepted. However, conventional direct-manipulation interfaces 
have some well-recognized limitations. For example, Unix users can write param¬ 
eterized macros (shell scripts) that perform common and repetitive tasks, but this 
is very difficult or impossible in the Macintosh Finder and other visual shells. 
Direct-manipulation interfaces also do not provide convenient mechanisms for 
expressing abstractions and generalizations, such as “all the objects of type y” or 
“do command z if the disk is almost full.” As a result, experienced users of direct- 
manipulation interfaces find commonly occurring complex tasks more difficult to 
perform than should be necessary. 

Demonstrational interfaces let the user perform actions on concrete example 
objects (often by direct manipulation), while constructing an abstract program. 
Thus, the user can create parameterized procedures and objects without learning 
a programming language. The term “demonstrational” is used because the user 
demonstrates the desired result using example values. For instance, suppose a user 
wants to delete all the “.ps” files from a directory. If the user dragged a file named 
“vl.ps” to the trash can, and then a file named “v2.ps,” a demonstrational system 
might notice that a similar action was performed twice and pop up a window asking 
if the system should delete the rest of the files that end in “.ps.” 

In addition to providing programming features, demonstrational interfaces can 
make direct-manipulation interfaces easier to use. For example, if the system 
guesses the user’s next operation based on the previous actions, the user might not 
have to perform it. 
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Do computers “guess”? 

A number of readers have objected to applying the term “guess” to computers. 
For example, on a panel at the SIGCHI 91 conference, Ben Shneiderman 
claimed that since computers execute deterministic algorithms, this term is inap¬ 
propriate. 1 I use the term for systems that use heuristics, since it appears to us¬ 
ers that the system is guessing their intent. Any system with heuristics will some¬ 
times generate an incorrect result. To users, such systems will seem to have a 
style of interface significantly different from conventional interfaces in which the 
computer is always “right.” Under this definition, most artificial intelligence sys¬ 
tems guess, as do pattern recognition systems like scanners and character rec¬ 
ognizers. 

There is a separate argument as to whether it is appropriate for computers to 
use heuristic algorithms (to guess). In the same panel, Ben Shneiderman said, “If 
the computer performs complex inferences, then the users lose control, predict¬ 
ability can vanish, and the risk of uncertainty increases.” However, this article 
shows that heuristics can provide users with significant facilities that might not be 
achievable any other way, and that designers should not be afraid to use them. 
Proper attention to the feedback the interface presents to the user can overcome 
the problems that Shneiderman mentions. 

Reference 

1. B.A. Myers, A. Cypher, D. Maulsby, D.C. Smith, and B. Shneiderman, “Demonstrational 
Interfaces: Coming Soon?" panel discussion, Proc. SIGCHI, Human Factors in Comput¬ 
ing Systems, ACM, New York, 1991, pp. 393-396. 


This article defines demonstrational 
interfaces and related terms, and dis¬ 
cusses why these systems are important 
and how they can be used. Since the 
area of demonstrational interfaces is 
rather new, some of the article is specu¬ 
lative. The goal is to suggest the tech¬ 
nique’s possibilities and to inspire fur¬ 
ther research and development. 

Definitions 

In a demonstrational interface, the 
user operates on concrete examples, but 
the examples represent a more general 
class of objects. Significant differences 
exist among demonstrational interfac¬ 
es. One way to classify the systems is by 
whether they guess and whether they 
support full programming. 

User interfaces can use demonstra¬ 
tion in two ways. Some demonstration¬ 
al interfaces use inferencing, in which 
the system guesses the generalization 
using heuristics. Other systems do not 
try to infer the generalizations, and there¬ 
fore require the user to explicitly spec¬ 
ify which properties of the examples to 
generalize. A distinction between infer¬ 
encing and noninferencing systems is 
that an inferencing system guesses and 
can do an incorrect action even when 


the user makes no mistakes, whereas a 
noninferencing system will always do 
the correct action if the user is correct 
(assuming there are no bugs in the soft¬ 
ware, of course). 

Interfaces that use inferencing come 
under the general category of intelligent 
interfaces. This term refers to any user 
interface that has some “intelligent” or 
artificial intelligence component. The 
category includes demonstrational in¬ 
terfaces with inferencing, but also other 
interfaces such as those using natural 
language. 

Some demonstrational interfaces do 
not provide full programming. A pro¬ 
gram is usually defined as a sequence of 
instructions executed by a computer, so 
any system that executes the user’s ac¬ 
tions can be considered programmable. 
However, for this article, it is useful to 
characterize how programmable the 
systems are. Therefore, I use the term 
programmable for systems that can han¬ 
dle variables, conditionals, and itera¬ 
tion. It is not sufficient for the interface 
to be used for entering or defining pro¬ 
grams, since such systems would include 
all text editors. The interface itself must 
be programmable. 

Demonstrational interfaces that pro¬ 
vide programming capabilities are called 
example-based, programming systems. 


Interfaces that provide both program¬ 
ming and inferencing are called pro¬ 
gramming-by-example systems, which 
come under the topic of “automatic pro¬ 
gramming.” Programming-with-example 
systems, however, require the program¬ 
mer to specify everything about the pro¬ 
gram (there is no inferencing involved), 
but the programmer can work out the 
program on a specific example. The sys¬ 
tem executes the programmer’s com¬ 
mands normally but remembers them 
for later reuse. Example-based program¬ 
ming can be differentiated from con¬ 
ventional testing and debugging because 
the examples are used during code de¬ 
velopment, not just after coding. 

Table 1 shows how these categories 
create a taxonomy for classifying sys¬ 
tems. 

Motivation for 

demonstrational 

interfaces 

Most demonstrational interfaces are 
also direct-manipulation interfaces and 
share all the advantages of that style (as 
listed by Shneiderman 1 ): 

•Novices can learn basic functional¬ 
ity quickly. 

• Experts can work extremely rapidly 
to carry out a wide range of tasks. 

•Knowledgeable intermittent users 
can retain operational concepts. 

• Error messages are rarely needed. 

• Users can immediately see whether 
their actions are furthering their 
goals. If not, they can simply change 
the direction of their activity. 

• Users experience less anxiety be¬ 
cause the system is comprehensible 
and because actions are so easily 
reversible. 

In addition, demonstrational interfaces 


• allow abstract operations to be per¬ 
formed concretely, 

• provide programming capabilities to 
users without requiring any special 
programming knowledge, and 

•permit even easier and more effi¬ 
cient use than conventional direct- 
manipulation interfaces. 

These additional advantages are dis¬ 
cussed in the following sections. 
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Providing abstractions concretely. A 

primary feature of direct-manipulation 
interfaces is the “visibility of the object 
of interest.” 1 Users see on the screen 
the object to be operated on. However, 
when the operation that the user is try¬ 
ing to perform is an abstraction, there 
may be no object to make visible. For 
instance, it is impossible to allow the 
user to draw what a generic, abstract 
menu should look like. However, a dem- 
onstrational interface can display a few 
example objects to represent the ab¬ 
straction, and then the user can directly 
manipulate the examples. For the menu, 
the user could operate on an example 
set of strings, even though the resulting 
menu would work for any set of strings. 
Thus, demonstrational interfaces can 
extend the range of direct manipulation 
by providing visible objects that can be 
turned into abstractions. 

In some cases, the abstractions could 
be provided to the user, but most peo¬ 
ple are much better at dealing with spe¬ 
cific examples than with abstract ideas. 
Users make fewer errors when working 
out a problem on an example as com¬ 
pared with performing the same opera¬ 
tion in the abstract. Therefore, demon¬ 
strational interfaces may be easier to 
learn and understand than interfaces 
that require users to think abstractly. 

Programming capabilities. The vast 
majority of people who use computers 
do not know how to write conventional 
computer programs. As computer us¬ 
age increases, the number will become 
greater. However, providing program¬ 
mability is important to support user 
customization. Software supplied by 
vendors rarely does exactly what the 
customer requires, so features that let 
the typical user change the software are 
quite desirable. Spreadsheets are an 
example of how successful a product 
can be if it does provide programmabil¬ 
ity: When users write formulas and mac¬ 
ros for spreadsheets, they are program¬ 
ming. Unfortunately, other types of 
applications provide no natural program¬ 
ming capabilities. This is especially true 
for direct-manipulation applications, 
such as drawing, CAD/CAM, and icon¬ 
ic programs, where the only way to pro¬ 
gram is to escape to conventional textu¬ 
al languages that require the user to 
learn new and different skills. 

Demonstrational techniques can pro¬ 
vide these programming capabilities 
without requiring the user to learn a 


Table 1. A taxonomy of interfaces. 



Not Demonstrational 

Not Intelligent Intelligent 

Not Programmable 

Conventional direct 
manipulation 
interfaces 

Natural language interfaces 

Programmable 

Unix shell 

Programmer’s Apprentice 


Demonstrational 


Not Intelligent 

Intelligent 

Not Programmable 

Industrial robots 

MacDraw 


Macro makers 

Microsoft Word 

Scribe 

Editing by Example 

Notech 

Demonstrational Text Editor 

Programmable 

Emacs 

Thesys 


Pygmalion 

Peridot 


SmallStar 

Metamouse 


Tango 

Eager 


programming language. When the user 
gives the normal system commands, in 
addition to performing the customary 
action, the system records the commands 
for later reuse. Variables, loops, condi¬ 
tionals, and other programming features 
can then be added to the generated 
scripts explicitly by the user or auto¬ 
matically by the system using inferenc- 
ing. The result is a macro or procedure 
that can be used in multiple contexts. 
This technique has been successfully 
demonstrated by a system supporting 
the desktop metaphor 2 and by a system 
for user interface construction. 3 

Learning a programming language and 
writing programs are very difficult tasks 
for most people, so users will find it 
easier to create procedures this way. 
Even the basic concepts of program¬ 
ming, such as representing the problem 
to be solved as a sequence of steps, can 
be hard to learn. However, demonstra¬ 
tional programming overcomes these 
difficulties because the user interactively 
creates a solution to a concrete prob¬ 
lem, rather than working abstractly off 
line. Typically, with demonstrational 
systems, the users operate in the user 
interface that they are familiar with and 
have no language syntax to learn. 

Ease of use. Demonstrational inter¬ 
faces can be even easier to use than 
conventional direct-manipulation inter¬ 
faces. Most spreadsheet systems and 


some text editors, such as Emacs, let the 
user record a sequence of commands 
and replay them later. The user is creat¬ 
ing a “macro” by example, since the 
system executes the operations on ex¬ 
ample data while the user creates the 
macro. This has long been known as a 
very effective mechanism to help users 
create programs that can significantly 
decrease their work. 

Some systems have added inferenc- 
ing to this macro mechanism, so the 
system tries to guess the parameteriza¬ 
tion of the macro, where loops are ap¬ 
propriate, or even when a macro might 
be useful. Such inferencing has been 
successful in limited domains, such as 
creating drawings and animations. 4 

In addition to helping the user avoid 
repetitive actions, demonstrational in¬ 
terfaces can also infer semantic, high- 
level properties of the objects. Most 
direct-manipulation systems provide the 
user with a small number of simple and 
direct operations, out of which the de¬ 
sired high-level effects can be construct¬ 
ed. However, if the system can infer the 
user’s high-level intentions while he or 
she performs a composite operation, it 
can save the user from having to per¬ 
form a number of steps. For example, 
drawing packages let the user change 
the position and size of individual ob¬ 
jects or groups of objects. However, 
there are rarely tools that help with 
higher level effects such as moving ob- 
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jects so they are evenly spaced. A dem- 
onstrational system might watch the user 
move the first few objects and automat¬ 
ically infer this high-level property. 

Another example of inferencing for 
semantic properties is the determina¬ 
tion of the appropriate constraints to 
apply to objects. Constraints are sys¬ 
tem-maintained relationships among 
objects. For example, if an architecture 
system can infer that the user is placing 
the windows on the second story of a 
building, then it can automatically en¬ 
sure that they stay between the floor 
and ceiling, even if the user moves that 
story. 

In most cases, it would be possible to 
provide the user with a command to 
perform the same action that the system 
infers from the demonstration. Howev¬ 
er, providing inferencing instead of ex¬ 
tra commands has advantages: 

• Inferencing significantly decreases 
the number of commands and there¬ 
fore makes the system easier to use 
and learn. 

• Inferencing helps the user who does 
not have sufficient knowledge of 
programming techniques to combine 
the commands appropriately. 

• The system may be able to tell the 
user the correct high-level semantic 
property (such as “make evenly 
spaced horizontally”) when the user 
does not see what is needed. 

• The demonstrational system can be 
set up to always try to determine a 
high-level relationship. With a sys¬ 
tem that only has commands, the 
user might forget to apply the ap¬ 
propriate command. 

Problems with 

demonstrational 

interfaces 

Of course, there are some disadvan¬ 
tages to the demonstrational style. Some 
may be solved by future research but 
others seem fundamental to the tech¬ 
nology. 

Demonstrational interfaces are hard¬ 
er to use in cases where the user knows 
exactly the relationship desired and 
could select it from a menu. For exam¬ 
ple, to demonstrate that a value is sup¬ 
posed to toggle when an action occurs, 
the user must demonstrate the behavior 
twice: once when it was originally on, 


and once when it was originally off. 
Otherwise, the toggle case cannot be 
distinguished from always going on or 
always going off. Demonstrating this is 
probably more time-consuming than 
choosing among “toggle,” “set,” and 
“clear” in a menu. Clearly, designers 
should use demonstrational techniques 
only when appropriate. 

As mentioned earlier, some demon¬ 
strational systems attempt to infer the 
generalization from the examples. For 
instance, some systems try to guess when 
to perform a previous operation again. 
Clearly, any system that guesses will 
sometimes be wrong. In addition to per¬ 
forming the wrong operation, a bad guess 
causes other problems. First, the system 
must provide appropriate feedback 
about what it is doing, so users can find 
out when it is wrong. This feedback can 
be intrusive and can slow down normal 
operation. (Feedback in demonstration¬ 
al interfaces is discussed at length be¬ 
low.) Second, users must have a mecha¬ 
nism to abort or undo incorrect 
inferences. Providing this feature can 
make the interface much more difficult 
to implement. Third, users may be un¬ 
comfortable with an interface that oc¬ 
casionally does the wrong thing. Even if 
users’ overall productivity is higher, an 
occasional error may undermine their 
willingness to use the system (although, 
to some extent, appropriate feedback 
can make users feel that they know what 
the system is doing and that they con¬ 
trol it). Finally, if the user fails to detect 
an error, the system will create an erro¬ 
neous procedure. 

Studies have shown that user-gener¬ 
ated procedures for spreadsheets often 
contain errors. 5 Spreadsheet users must 
test and debug the procedures they write, 
but this has not deterred them from 
writing procedures. The same will apply 
to procedures generated from exam¬ 
ples. 

Survey 

The next sections use the taxonomy 
of Table 1 to survey various interfaces. 
It is probably easier to appreciate the 
differences between demonstrational 
and conventional direct-manipulation 
interfaces by seeing a videotape of a 
demonstrational system in action. Vid¬ 
eos of a number of the systems men¬ 
tioned in this article — including Small- 
Star, Peridot, Metamouse, and Eager 


— are available as Siggraph Video Re¬ 
views.* 

Not demonstrational. Although this 
article is about demonstrational systems, 
for context it is useful to characterize a 
few nondemonstrational systems accord¬ 
ing to the taxonomy of Table 1. 

Systems that are not demonstration¬ 
al, programmable, or intelligent are just 
the conventional user interfaces, includ¬ 
ing nonprogrammable command lines 
and most direct-manipulation systems. 
The intelligent, nondemonstrational, 
nonprogrammable interfaces include 
most of the systems developed by artifi¬ 
cial intelligence researchers, including 
natural language interfaces, intelligent 
help, and so on. All conventional sys¬ 
tems that allow the user to program in 
the interface are included in the catego¬ 
ry of programmable, nonintelligent in¬ 
terfaces. This includes the Unix shell 
and the programming language embed¬ 
ded in Emacs (called MockLisp in some 
versions). A system that can be classi¬ 
fied as intelligent, programmable, and 
not demonstrational is the Programmer’s 
Apprentice, 6 which uses AI to help the 
user create programs. 

Demonstrational, not programmable, 
not intelligent. Perhaps the simplest 
demonstrational interfaces are systems 
that record the user’s actions and allow 
them to be replayed later. For example, 
some industrial robots are trained by 
moving the robot’s limbs through the 
desired motions. The robot will then 
repeat these motions. 

Systems that save keystrokes the user 
types and replay them later are also 
classified as demonstrational, not pro¬ 
grammable, and not intelligent. The most 
famous example of this is in the Emacs 
text editor, but since Emacs adds loops 
and conditionals, it is classified as a 
programmable demonstrational inter¬ 
face (see below). Many spreadsheet pro¬ 
grams can record the user’s keystrokes 
to construct a macro as the user sees the 
results of the macro executed on exam¬ 
ple data. 

Simple transcripting like this has also 
been used in mouse-based programs for 
the Macintosh user interface, such as 
Apple’s MacroMaker. Unfortunately, 
transcripting is less successful here than 


* Order from ACM Siggraph, do First Priority, PO 
Box 576, Itasca, IL 60143, phone (800) 523-5503. 
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Figure 1. When the user selects an object in MacDraw (a) 
and then executes the Duplicate command, the new object 
appears at a standard offset from the original (b). If the 
user moves the new object (c) and gives the Duplicate 
command on it, the subsequent object is offset from the 
second object the same as the second was from the first 
(d). This is a simple example of inferring the desired posi¬ 
tion from the user’s example. 


in text editors or robots be¬ 
cause the transcripting pro¬ 
grams are not tied to a partic¬ 
ular application and therefore 
can save only raw mouse and 
keyboard events. For exam¬ 
ple, the transcript will save 
information such as “the 
mouse button went down at 
location (23,456).” The fact 
that there was a particular 
icon at that location may not 
be recorded. If the windows 
and icons move after the mac¬ 
ro is created, the locations 
saved may not correspond to 
the correct objects, so the 
macros will not work correct¬ 
ly. Some programs, such as 
Tempo II from Affinity Mi¬ 
crosystems and QuicKeys 
from CE Software, make a 
transcript of somewhat high¬ 
er level commands, but in 
general it is necessary to have 
specific high-level knowledge about the 
application being run to make transcript¬ 
ing robust. 

Demonstrational, not programmable, 
intelligent. The intelligent demonstra¬ 
tional systems try to guess something 
about what the user is doing. However, 
the amount of inferencing done by these 
systems can vary significantly. 

A number of popular systems use in¬ 


ferencing in very simple ways. For ex¬ 
ample, the Macintosh programs Adobe 
Illustrator and Claris MacDraw re¬ 
member the transformations used on 
graphic objects after a Duplicate oper¬ 
ation, guess that the user wants the same 
transformations for new objects, and 
apply them automatically (see Figure 
1). The guess may be incorrect, and the 
new object may even appear off the 
screen (if the initial transformation was 


large), but usually this fea¬ 
ture is helpful. 

When the user executes the 
Renumber command in Mi¬ 
crosoft Word 4.0 for the 
Macintosh, it looks at the first 
paragraph in the selection and 
determines whether it has a 
number. If so, Word uses the 
number’s formatting to de¬ 
termine how the numbers at 
the beginning of all the para¬ 
graphs should look (see Fig¬ 
ure 2). For example, if the 
paragraph starts with “3)” 
Word guesses that para¬ 
graphs should be numbered 
using a numeral followed by 
a parenthesis. It will also 
guess about multilevel num¬ 
bering, so if the example has 
Roman numerals on main 
paragraphs and letters on in¬ 
dented paragraphs, Word will 
renumber all the levels ap¬ 
propriately. Microsoft Word will guess 
wrong in some cases, however. For ex¬ 
ample, in Figure 2 Word has changed 
the punctuation after the lowercase 
Roman numerals from parentheses to 
periods, which is probably not what the 
user had in mind. 

The Scribe text formatter provides 
another small use of inferencing from 
an example in its formatting for the 
date. When specifying the way the date 


Figure 2. When the user gives the 
Renumber command in Microsoft 
Word 4.0 for the Macintosh, an op¬ 
tion is to renumber By Example (a). 
The system will look at the number¬ 
ing at the start of each paragraph 
and use the format to guess how to 
renumber paragraphs indented at 
that level. In (b), Word has inter¬ 
preted the example number format¬ 
ting at the different levels, it has 
fixed the numbers to be in order, 
and it has added numbers to para¬ 
graphs that did not have any. How¬ 
ever, it changed the parentheses in 
the inner sections to periods. 
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Chapter II 

Related Work 


Figure 3. A chapter heading that includes different formatting for different parts. 

A X( 

Start-Recording 

A S.PS 

Find “.PS" and move cursor to just before it 

A A 

Go to beginning of that line 

print 

Insert the word print 

A N A A 

Go to the beginning of the next line 

a x) 

Stop-Recording 

A U99 A X E 

Do the recorded macro repeatedly for the rest of the file 
(actually, do it 99 times or until the search fails) 


Figure 4. Commands for recording and executing a macro in Emacs. 



should be printed, the user can supply 
an example in nearly any notation for 
the particular date March 8, 1952, and 
Scribe will convert this for use with the 
current date. Scribe accepts formats like 
the following for specifying how the 
current date should be printed: 

@Style(Date=“03/08/52”) 
@Style(Date=“March 8,1952”) 
@Style(Date=“Saturday, 8th of 
March”) 

@Style(Date=“8-Mar-52”) 
@Style(Date=“the eighth of 

March, nineteen fifty-two”) 

Another use of heuristics in a com¬ 
mercial product is that, when you ask 
for a chart or plot in many spreadsheet 
packages, the system will try to guess 
what kind would be best, based on the 
form of the data. 

Among research systems, Editing by 
Example, 7 uses demonstrational tech¬ 
niques to create transformations of the 
text (for example, replace “this” with 
“that”). The system compares two or 
more examples of the input and the 
resulting output of a sequence of edit¬ 
ing operations to deduce what are vari¬ 
ables and what are constants. Usually 
the system can generate correct pro¬ 
grams given only two or three exam¬ 
ples, and it uses heuristics to generate 
programs from single examples. For in¬ 
stance, the system can deduce a pro¬ 
gram to convert all occurrences of 
“@i (<text>)” to “(\sl <text>}” if the user 
edits “@i(O.K.)” to “{\sl O.K.}” and 
then edits “@i(Boston Post)” to “{\sl 
Boston Post).” Then the user can run 
this program on other parts of the doc¬ 


ument. Unlike the Emacs macros, how¬ 
ever, Editing by Example uses the re¬ 
sults of the text editing, not the particu¬ 
lar editing operations used. The primary 
inferencing here is to differentiate vari¬ 
ables from constants. 

With the Notech text formatter from 
Princeton University, users type docu¬ 
ments in plain text with no formatting 
commands. The system tries to infer the 
appropriate formatting from the spac¬ 
ing and contents of the document to 
produce attractive laser printer output. 
For example, Notech assumes that a 
single line is a header, a group of short 
pieces of text separated by tabs is a 
table, and text that contains Pascal or C 
statements is code. Notech is a prepro¬ 
cessor for Tex and uses a set of rules to 
parse the input. 

The Demonstrational Text Editor 8 lets 
the user create text formatting macros 
by example. The “styles” supplied by 
formatters like Microsoft Word look 
only at the first character of the selec¬ 
tion, so they do not capture the format¬ 
ting information of the chapter heading 
shown in Figure 3. The Demonstration¬ 
al Text Editor, however, lets the user 
enter that heading, select it, and create 
a style from it. The system tries to infer 
the roles of the various parts using heu¬ 
ristics. These are based on typical docu¬ 
ment structure (numbers versus regular 
text, special words such as “chapter” 
and “section,” separators such as peri¬ 
ods, colons, and so on). After the macro 
is created by example, the next time a 
chapter or section is needed, the user 
can type in the title and apply the macro 
to it. If the user edits the formatting of 
any heading, the changes are reflected 


in all other headings. The system also 
has a demonstrational method for spec¬ 
ifying tables. The user draws an exam¬ 
ple of the desired table using a special 
graphical editor, and the system expands 
and contracts the table as needed for 
the actual data. 

Demonstrational, programmable, not 
intelligent. All programmable, demon¬ 
strational systems are classified as ex¬ 
ample-based programming. When there 
is no intelligence, they are called pro- 
gramming-with-example systems. 

Perhaps the simplest programmable 
demonstrational interface is the key¬ 
board macro facility in Emacs. Here, 
the user goes into program mode, gives 
a number of commands in the usual 
way, and then leaves program mode. 
The commands execute normally while 
the macro is being created, so the user 
has to learn only three new commands 
to use macros: Start-Recording, Stop- 
Recording, and Execute Macro. The 
rest of the commands are the ones used 
every day while editing. To replay the 
macro, the user moves the cursor to the 
appropriate new place and gives the 
Execute Macro command. 

For example, to put “print” in front 
of every line of a file that contains the 
characters “.PS,” the user can perform 
the actions shown in Figure 4. 

Emacs’ macro facility is classified as 
programmable because macros are pa¬ 
rameterized by cursor location, macros 
can have implicit conditionals (they exit 
when a search fails), and loops can be 
specified. 

Pygmalion 9 was the seminal system 
that used demonstrational techniques 
for general-purpose programming and 
was developed in 1975. Pygmalion, which 
supported programming using icons, did 
not use inferencing. The user moved 
icons around to demonstrate to the sys¬ 
tem how to carry out a computation. 

SmallStar 2 lets the user program a 
prototype version of the Star office 
workstation desktop. The desktop, 
sometimes called the visual shell, is an 
iconic interface that supports file cre¬ 
ation, deletion, moving, copying, print¬ 
ing, and filing in directories (called fold¬ 
ers). When programming with SmallStar, 
the user enters program mode, performs 
the operations to be remembered, and 
then leaves program mode. SmallStar 
executes the operations in the actual 
system user interface, which the user 
already knows. It generates a textual 
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representation of the actions, which the 
user can edit to differentiate constants 
from variables and explicitly add con¬ 
trol structures such as loops and condi¬ 
tionals. 

An important innovation in Small- 
Star is the dialogue boxes that let the 
user generalize from a particular exam¬ 
ple object. The user might select a par¬ 
ticular file, such as “Treaty,” but actual¬ 
ly want to refer to the first file in a folder 
(directory) or all files that start with 
“T.” As Figure 5 shows, SmallStar iden¬ 
tifies the most common ways of describ¬ 
ing data and provides these in a dia¬ 
logue box. Other generalizations, such 
as for control structures, are similarly 
presented. 

A “program visualization” system lets 
the user view the execution of a com¬ 
puter program using pictures. A num¬ 
ber of systems allow the user to specify 
the desired picture by demonstration. 
For instance, Tango 10 lets the user draw 
example pictures of the objects to ap¬ 
pear in the animation, and then attach 
the various properties of the objects to 
appropriate program variables and ac- 



Choose using POSITION | PROMPT | ANY | 

Name Pattern | Treaty| 


| BEFORE I AFTER | BETWEEN | ANY] 


Date and time | 09/23/94 11:57;30 1 
... and date and time | 09/23/94 11:57:30~| 

Prompt | Please select a Document | 
Position __ ] 


Figure 5. SmallStar 2 uses this dialogue box to generalize from the chosen icon 
to create a general-purpose procedure. The Name Pattern can contain to 
match any sequence of characters. 


Automatic programming 


Demonstrational, programmable, in¬ 
telligent. Demonstrational systems that 
are programmable and intelligent are 
called programming-by-example sys- 

The use of inferencing with demon¬ 
stration to create programs has a long 
history. Early systems tried to infer gen¬ 
eral-purpose programs from examples 
of input and output. The Thesys system 
would try to generate an appropriate 
Lisp procedure from multiple examples 
of the input and resulting output lists. 11 
However, this type of system could in¬ 
fer only relatively simple programs. (See 
the sidebar on automatic programming 
for more details.) 

Inferencing has been more successful 
when applied to generating highly con¬ 
strained special-purpose programs. For 
example, the Peridot system 3 allows a 
designer to create user interface com¬ 
ponents such as menus, scroll bars, and 
buttons with a graphical editor. Exam¬ 
ple values for such things as the items in 
the menu and the position of the scroll 
bar indicator let the designer construct 
the interfaces by direct manipulation. 
Peridot uses inferencing to guess 

• how the various graphic elements 
depend on the example parameters 


Automatic programming, which is also called “programming by example,” was a 
hot topic in artificial intelligence in the early 1970s. Automatic programming is 
when computers use intelligence (or heuristics) to generate programs from some 
sort of simple specification. A comprehensive survey of this area appears else¬ 
where. 1 

An early system of this type was the “Trainable Turing Machine,” 2 in which the 
user supplied examples of the Turing Machine’s input, output, and head move¬ 
ments during a computation, and the system algorithmically created its own finite- 
state controller that handled a class of “similar” computations. Thesys was anoth¬ 
er automatic programming system that attempted to infer programs from input 
and output, and is discussed in the text. However, it is generally impossible to in¬ 
fer a program from only examples of input and output, so these systems were 
successful only for very limited classes of programs. 

Another approach, exemplified by Autoprogrammer, 3 attempts to infer general 
programs using examples of program execution traces. The user gives all the 
steps of one or more passes through the execution of the procedure on sample 
data. Then, the system tries to determine where loops and conditionals should 
go, as well as which values should be constants and which should be variables. 
The authors hoped that this approach would expand the class of programs that 
could be automatically inferred, but it was not very successful for general- 
purpose programming. 

Because these early systems were not successful, automatic programming is 
not an active area for current Al research. The modern demonstrational systems 
discussed in this article have revived some of these techniques and applied them 
to much more limited domains — not general-purpose programming. The added 
context provided by limited domains allows the demonstrational systems to guess 
correctly most of the time. 
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Figure 6. Creating a set of check boxes with Peridot. As the user draws the graphics for the check boxes, Peridot guesses 
how the rectangles are arranged with respect to the example parameters (the strings to be displayed). Then, when the 
user finishes the first two elements of a list (a), Peridot infers the need for an iteration (shown in the prompt window at 
the bottom). If the user confirms this guess. Peridot automatically creates the rest of the items of the iteration (b). Peri¬ 
dot infers the need for an iteration from two examples. When the mouse icon is placed over the check mark in the second 
box (c), Peridot infers that it should be a feedback object. 


(for example, that the menu’s bor¬ 
der should be big enough for all the 
strings), 

’when an iteration is needed (for 
example, to place the rest of the 


menu items after the user has dem¬ 
onstrated the positions for two), and 
1 how the mouse should control the 
interface (for example, to move the 
indicator in the scroll bar). 



Figure 7. Eager displays the cat icon to show which menu item it thinks the user 
will select next. (Picture courtesy of Allen Cypher.) 


Figure 6 shows how the user can create 
check boxes using Peridot. 

Metamouse 4 is also based on a graph¬ 
ical editor, but it watches as the user 
creates and edits pictures in a two- 
dimensional click-and-drag drafting 
package. Metamouse tries to generalize 
from the actions to create a general 
graphical procedure. If the user appears 
to be performing the same edits again, 
the system will perform the rest of them 
automatically. Metamouse uses infer- 
encing to identify geometric constraints 
in editing operations, to determine where 
conditionals and loops are appropriate, 
and to differentiate variables from con¬ 
stants. 

Eager 12 is a “smart macro” tool for 
the HyperCard environment (see Fig¬ 
ure 7). HyperCard is a Macintosh pro¬ 
gram that lets users build custom, di¬ 
rect-manipulation applications. Like 
Metamouse, Eager infers an iterative 
program to complete a task after the 
user has performed the first two or three 
iterations. An innovation in Eager is its 
technique for providing feedback to the 
user about how the system has general¬ 
ized the user’s actions. Eager provides 
feedback by anticipation: When it rec¬ 
ognizes a pattern, it infers what the us¬ 
er’s next action will be and uses color 
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and a special icon to highlight the loca¬ 
tion where the user will next click the 
mouse (if it is on a menu item or a 
button on the screen) — or it displays 
the text that it expects the user to type 
next. (Most other systems — for exam¬ 
ple, Peridot and Metamouse — explain 
in text what the user is expected to do.) 
If the user performs the action Eager 
anticipated, this confirms the inference; 
if the user performs a different action, 
this provides a new example for Eager 
to use in determining a better inference 
about how to generalize the user’s ac¬ 
tions. 

Application areas 

As may be evident from the survey 
section, there are many small examples 
but as yet no large-scale uses of demon- 
strational techniques in commercial sys¬ 
tems. However, demonstrational inter¬ 
faces can be successfully used in many 
different kinds of programs. A demon¬ 
strational interface might be appropri¬ 
ate for an application with one or more 
of the following characteristics: 

• high-level domain knowledge that 
could be represented in the pro¬ 
gram, 

• low-level commands that users re¬ 
peatedly perform in some situations, 

• a textual, command-line interface 
and a graphical, direct-manipulation 
interface, with some programming¬ 
like features available in the former 
but missing from the latter, and 

• a user interface or program output 
with limited options, which users 
want to customize. 

The following sections discuss some 
areas that would benefit from demon¬ 
strational technology, including some 
in which it has already been applied. 

General-purpose programming. Pyg¬ 
malion and Thesys explored the use of 
demonstration for general-purpose pro¬ 
gramming. So far, the evidence suggests 
that beginning programmers might ben¬ 
efit from demonstrational techniques, 
but expert programmers do not. An 
important trend in user interfaces, how¬ 
ever, is to provide programming fea¬ 
tures to users who are not necessarily 
programmers. Spreadsheet formulas and 
macros, database programs created with 
dBase, and Macintosh HyperCard scripts 


are all forms of user programming. Dem¬ 
onstrational techniques are already be¬ 
ing used to some extent and can be 
expanded to further help users create 
successful programs. In addition to help¬ 
ing users debug by presenting the re¬ 
sults of program execution on example 
data, systems can use inferencing to guess 
some properties of programs, so users 
will not need to specify them. 

Visualization. If demonstrational tech¬ 
niques have not always been convincing 
for entering general programs, they have 
been proved for visualizing the pro¬ 
grams. Tango and related systems have 
shown that allowing the user to draw 
the desired display makes it much easi¬ 
er to create algorithm animations. A 
similar technique might be used for sci¬ 
entific visualization: The scientist could 
sketch the desired picture when speci¬ 
fying the display for large amounts of 
data, without requiring the services of a 
programmer. 

With inferencing added, the system 
could guess how to generalize from the 
example pictures to the actual data. For 
instance, there are many different ways 
to display a binary tree. The user could 
draw a sample display and the system 
could use the example to choose a type 
of tree display and the appropriate pa¬ 
rameters. The user would not have to 
understand the meanings of the various 
layout options and parameters. 

Macros for direct-manipulation in¬ 
terfaces. Macro recorders for direct- 
manipulation interfaces are quite wide¬ 
spread, but they need additional 
programming features to make them 
more useful. The SmallStar system 
showed that users can add control struc¬ 
tures and variables to macros, if the 
system presents them appropriately. 
Future research should determine how 
to apply these ideas to other domains so 
higher level operations, rather than key¬ 
strokes, are recorded. Then macros will 
still work if objects move around or 
change names. 

Systems combining inferencing with 
macro recorders can guess where the 
variables and control structures should 
be, without requiring users to specify 
them. The Eager system shows that iter¬ 
ation can be guessed successfully. In¬ 
stead of requiring the user to select the 
example object and explicitly general¬ 
ize it, the system might watch two exam¬ 
ple operations, notice that a different 


object was used, and create a variable 
automatically (as in the example of de¬ 
leting “.ps” files given at the beginning 
of the article). 

Drawing packages. Many drawing 
packages use demonstrational tech¬ 
niques in different ways, almost all in¬ 
volving inferencing. Uses range from 
guessing the position for the duplicated 
objects, as in MacDraw, to inferring 
programs from example drawings, as in 
Metamouse. 

Future research should be directed at 
inferring graphical properties from the 
example pictures. One common prob¬ 
lem with simple drawing packages like 
Macintosh MacDraw is that there is no 
mechanism for specifying how the 
graphical objects relate to one another. 
For example, a user may affix a line to 
a box, but it will not stay attached if 
the user moves the box. Other drawing 
packages have addressed this problem 
by allowing the user to specify con¬ 
straints on the objects. Unfortunately, 
users often have a difficult time under¬ 
standing and correctly specifying con¬ 
straints. 

Peridot demonstrated that it is possi¬ 
ble for a system to successfully guess 
graphical constraints on objects if the 
system knows the type of drawing. This 
technique could be used in more gener¬ 
al drawing packages so that parts of the 
pictures could be edited and still retain 
important properties. Another advan¬ 
tage to the demonstrational approach is 
that the constraints are guaranteed to 
correctly create the example picture. 
On the other hand, when the user ex¬ 
plicitly applies constraints, they can 
result in a situation with no possible 
solution. 

Inferencing could also help users cre¬ 
ate objects neatly. In many direct- 
manipulation interfaces, certain points 
attract the cursor when it is moved near 
them, making it easier to create the 
desired pictures. For example, if the 
cursor is close to the endpoint of a line, 
it will jump to be exactly on the end¬ 
point (as if attracted by gravity). This 
idea can be extended to provide in¬ 
ferred gravity points. For example, if 
the user has drawn two objects a certain 
distance apart, the system could insert a 
gravity point at the same distance from 
the second object, in case a third is 
desired. In a similar way, the positions 
and sizes for alignment lines and circles, 
as used in computerized “ruler” and 
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“compass” tools, might also be inferred 
from the drawing. 

Text editing and formatting. As stat¬ 
ed previously, demonstrational tech¬ 
niques in text editing and formatting 
include Emacs’ creation of macros by 
example, Microsoft Word’s renumber¬ 
ing by example, and Scribe’s date for¬ 
matting by example. Notech infers the 
formatting for a document from its plain¬ 
text appearance. The Demonstrational 
Text Editor creates styles and tables by 
example, but there are plenty of oppor¬ 
tunities for further applications in this 
area. 

User interface development environ¬ 
ments. Demonstrational techniques have 
been very popular for creating user in¬ 
terface software. The Peridot system 
was discussed earlier; other systems are 
listed in the sidebar on user interface 
tools. It seems natural to let the design¬ 
er demonstrate the user’s actions and 
the system’s responses. Current research 
is directed at expanding the amount of 


the interface that can be specified by 
demonstration. 

Other areas. Many other areas would 
benefit from demonstrational tech¬ 
niques. A popular style of video game 
has a number of characters, some good 
and some bad, and they interact in var¬ 
ious ways. For example, they jump, walk, 
shoot, and bump into other characters. 
Demonstrational techniques could be 
used to create a “video game construc¬ 
tion kit” that would allow users to draw 
the characters with a drawing package 
and then define their movements and 
behaviors by demonstration. This is fea¬ 
sible since the behaviors and interac¬ 
tions among characters are usually fair¬ 
ly simple. 

Demonstrational techniques might 
make spreadsheet programming easier. 
Systems might automatically determine 
which cell references should be vari¬ 
ables and which should be constants 
when users construct macros or copy 
formulas from one cell to another. 

Also, demonstrational techniques 


might be helpful when a user needs 
information about how to achieve a cer¬ 
tain task. Current help systems are good 
at explaining what a command does, but 
very poor when the user has a task in 
mind but does not know how to achieve 
it. For example, the user may want to 
sort some items or move a row of ob¬ 
jects down. The user could perform a 
few low-level actions that embody some 
required steps, and the system could try 
to guess appropriate high-level com¬ 
mands. 

Among the many other possible ap¬ 
plications of this technology are the cre¬ 
ation of educational software and ani¬ 
mations. Further research is needed to 
determine where demonstrational tech¬ 
niques can be profitably applied. 

Uses for demonstrational techniques. 

Looking at application areas and exist¬ 
ing implementations, we can identify 
some specific uses of demonstrational 
techniques. Many span multiple appli¬ 
cation areas: 

• Recording actions to create a macro 
or procedure. Emacs, SmallStar, 
Metamouse, and many other sys¬ 
tems use this technique. 

• Generalizing to create procedures 
from examples of input and output, 
as in Editing by Example and The- 
sys. 

• Flandling repetitive actions automat¬ 
ically. Many demonstrational sys¬ 
tems try to detect loops automati¬ 
cally. Examples include Peridot, 
Eager, and Metamouse. 

•Neatening pictures. Peridot and 
Metamouse try to detect graphical 
properties of objects so that users 
can draw them quickly and sloppily, 
relying on the system to straighten 
them out. 

• Generalizing a picture. Peridot uses 
the example pictures to represent a 
class of objects. 

• Determining high-level properties. 
The system generalizes from the 
examples to determine the proper¬ 
ties. For example, Notech uses this 
technique to determine the role of 
the text. 

Research issues 

Although some interfaces that use 
demonstrational techniques have been 
built, there has been no systematic study 


Demonstrational techniques 
for user interface tools 

Many researchers have applied demonstrational interfaces to user interface 
construction tools. The Peridot system is mentioned in the text, and there are 
many others. Lapidary 1 lets designers create application-specific graphical ob¬ 
jects by demonstration without programming. For example, the designer can draw 
examples of the boxes and arrows that will be the nodes and arcs in a graph edi¬ 
tor. Lapidary’s goal is to allow the designer to draw all the program’s graphical 
aspects using the mouse, and to define most aspects of interface behavior by 
demonstration without programming. Lapidary does not use inferencing. 

Druid 2 tries to guess the alignment of predefined widgets (such as buttons and 
menus) when the designer places them in a user interface. It also allows the de¬ 
signer to demonstrate the sequence of end-user actions (for example, after the 
user hits this button, gray out that button and pop up this dialogue box). 

The Mike user interface management system 3 lets designers specify macros by 
example for a wide range of user interfaces. It does not use inferencing. While 
creating a macro, the designer can insert a variable reference by adding a special 
parameter and then referring to the parameter instead of to an actual object. The 
system will then prompt the designer to give an example value for that parameter 
to be used in the rest of the demonstration. Designers can add control structures 
explicitly by first selecting the type of iteration or conditional from a menu, and 
then demonstrating the statements that go inside the control structure. 
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of this technology. A number of signif¬ 
icant problems remain to be solved by 
future research: 

Convincing users. Few systems use 
these techniques, so people are not yet 
convinced that they are feasible and 
beneficial. Future research should cre¬ 
ate example systems in different appli¬ 
cation areas and release these systems 
so that many people can use them. Us¬ 
ers’ reactions will help identify appro¬ 
priate applications for demonstrational 
interfaces. 

Finding the best use. It is not obvious 
how to use demonstrational techniques. 
Some aspects of the user interface are 
best performed by menus, some by di¬ 
rect manipulation, and some by demon¬ 
stration. The challenge is to determine 
which is most appropriate for what. As 
discussed earlier, demonstrational in¬ 
terfaces can be useful to present ab¬ 
stractions, which can be represented by 
one or more examples that the user can 
manipulate directly. 

Dealing with errors. Making the sys¬ 
tem guess correctly is difficult. All in- 
ferencing systems sometimes guess 
wrong, and the inferred procedures may 
contain errors. User interface designers 
are reluctant to use a technology that 
may make errors. Human factors stud¬ 
ies are required to determine when in- 
ferencing is beneficial to users despite 
the occasional errors. 

Building effective systems. Among the 
difficulties in building demonstrational 
systems are providing appropriate feed¬ 
back and allowing editing and debug¬ 
ging- 

Easing implementation. All existing 
programs have been separately and la¬ 
boriously implemented by hand. Tool 
kits and other support software are need¬ 
ed for demonstrational interfaces. 

The following sections discuss some of 
these topics in more detail. 

Human factors experiments. There 
have been some informal human fac¬ 
tors studies of demonstrational inter¬ 
faces. While they are far from conclu¬ 
sive, the studies suggest that users like 
this style of interface and can use it to 
create programs — and that further re¬ 
search is warranted. 

For example, experiments showed that 
experienced Star users who were not 
programmers could create moderately 
complex programs using SmallStar. 2 


Peridot was tested on five nonprogram¬ 
mers and five programmers, and all were 
able to create user interface elements 
such as menus after about an hour and a 
half of instruction. Creating a menu with 
a custom appearance took them about 
15 minutes, whereas it took the most 
experienced programmers one to eight 
hours to code using conventional pro¬ 
gramming languages. 3 Users of Peridot 
did not seem to mind that the system 
occasionally guessed incorrectly. 

The Eager system was also tested with 
users. 12 The system usually guessed the 
correct loops in the users’ programs, 
but users were nervous about letting the 
system do the rest of the iterations, be¬ 
cause they were not confident that the 
system would do them correctly. A par¬ 
ticular problem was that the stopping 
criterion was not made apparent to the 
users. 

Much more work is needed to evalu¬ 
ate when and how to use demonstra¬ 
tional interfaces, and how to provide 
feedback and other aids so users are 
comfortable with them. 

Specifying programs without infer- 
encing. When the system does not use 
inferencing, the user must specify the 
generalizations and control structures 
to transform the example objects and 
actions into a more general-purpose 
program. How to provide these capabil¬ 
ities to the user is an important ques¬ 
tion. SmallStar introduced a special- 
purpose language, but in many cases, 
this would be difficult for users to han¬ 
dle. What other approaches are there? 

Inferring correctly. Demonstrational 
interfaces that attempt to infer the us¬ 
er’s actions are quite difficult to build. 
Generally, much user testing and proto¬ 
typing are needed to determine wheth¬ 
er the system is correct often enough. 
An important design issue is whether a 
system should try to guess after a single 
example or after multiple examples. 
Clearly, it is easier for the user to spec¬ 
ify only one example, but the system is 
more likely to guess wrong. For instance, 
after each graphical object is drawn, 
Peridot immediately tries to guess how 
that object is related to previous objects 
in the scene. Metamouse, on the other 
hand, waits for two or more repetitions 
of the same action. In general, most 
systems that infer loops require multi¬ 
ple examples, and most systems that 
infer properties from objects guess im¬ 


mediately when the objects are created. 

Even if the generated procedure seems 
to operate correctly on the example data, 
it may not work for other important 
cases. Studies have shown that user¬ 
generated procedures for spreadsheets 
are often incorrect, 5 so it will be inter¬ 
esting to see whether demonstrated pro¬ 
cedures turn out to be more reliable in 
practice than those programmed by 
users. 

Feedback in demonstrational inter¬ 
faces. Inferencing systems will some¬ 
times guess wrong. An important prob¬ 
lem is how to inform users of the system’s 
inferences for verification or correc¬ 
tion. The trade-off is between giving 
users confidence that they know what 
the system is doing and that it is correct, 
and the interruption and loss of effi¬ 
ciency that feedback often causes. Suc¬ 
cessful systems will probably use multi¬ 
ple styles of feedback for various parts 
of the interface. The following sections 
suggest different ways to provide feed¬ 
back. 

Showing the generated code. One way 
to represent the generated program is 
to show the code — this technique is 
used by SmallStar. If users can under¬ 
stand the code, they have a natural way 
to check the system’s inferences and 
edit the results. Also, knowing the tex¬ 
tual programming language is sometimes 
an advantage. Systems that generate 
code automatically during a demonstra¬ 
tion help users learn the language. It is 
much easier to recognize the correct 
code than to generate it. However, many 
people find it difficult to comprehend 
textual languages. 

Question and answer. Peridot and 
Metamouse use the question-and- 
answer style. The system asks the user, 
with canned English sentences, wheth¬ 
er each inference is correct. This is easy 
to implement and well-liked by Peri¬ 
dot’s users, but it can be modal, disrup¬ 
tive, and error prone. Users tend to 
answer every question with “yes” (per¬ 
haps assuming that the computer knows 
best) rather than carefully read the 
messages to determine whether the in¬ 
ference is really correct. Question and 
answer can be implemented using a spe¬ 
cial prompt window in which the mes¬ 
sages always appear, or using pop-up 
alert boxes if the messages do not occur 
very frequently. 
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Figure 8. Metamouse shows the selection “handles" differently depending on 
the role that it has inferred for the object. Black handles indicate the object be¬ 
ing grasped, and dark gray handles show an object directly touched by the tur¬ 
tle icon. Light gray is for indirect touches. The handle size represents impor¬ 
tance. (Picture courtesy of David Maulsby.) 


Dialogue boxes. Some systems show 
the user what they guessed by setting 
values in menus or dialogue boxes (also 
called property sheets or forms). The 
user sees the inference in the dialogue 
box and then can modify it if necessary. 
For example, if the user is designing the 
formatting for an itemized list, the sys¬ 
tem could create a dialogue box show¬ 
ing all the possibilities for the format¬ 
ting of the various parts with the inferred 
choices highlighted. If the user is happy, 
he or she hits the OK button. If not, the 
user selects different values. In addi¬ 
tion, there could be a Next Guess but¬ 
ton that prompts the system to try a 
different guess. 

Listing all alternatives in a menu. When 
the example is ambiguous, the system 
can list all the possibilities in a menu 
and let the user select the correct one. 
The system might present the list, with 
the first items being those it thinks are 
most likely. 

Highlighting significant features. A 
system might highlight properties of the 
example it considers important. For ex¬ 
ample, Metamouse puts different styles 
of selection boxes (sometimes called 
“handles”) on graphical objects to show 
which locations it considers important 
(see Figure 8). If the system has guessed 
incorrectly, the user can click on the 
boxes to change their status. 

Anticipation. Eager uses a related idea. 
The next menu item or button that the 


system thinks the user will select is high¬ 
lighted using an icon and a special color. 
If the user sees that the system is guess¬ 
ing the correct operations, he or she will 
have more confidence that the system 
understands the task and may let it per¬ 
form the rest of the operations. 

No Feedback. Another possibility is 
for the system just to perform the in¬ 
ferred action immediately. The action 
itself may provide sufficient feedback. 
Obviously, this is most successful where 
the action will have some visible conse¬ 
quence, as in drawing or editing graph¬ 
ics. An easy-to-use undo facility is espe¬ 
cially important. For example, the 
Table-Maker that is part of the Demon- 
strational Text Editor 8 immediately ad¬ 
justs (beautifies) the graphical table com¬ 
ponents as the user enters them. After 
each line or string is drawn, it is moved 
to where the system has guessed it should 
be. If this was wrong, the user hits “Undo 
Guess.” 

Editing. An interesting problem in all 
demonstrational interfaces is how to let 
the user edit the constructed programs. 
When a textual representation is creat¬ 
ed, as in SmallStar, it can be edited. 
However, most demonstrational sys¬ 
tems do not produce a textual represen¬ 
tation. In fact, many assume that each 
inferred property or procedure will be 
small enough so that it is acceptable to 
delete the old one in its entirety and 
demonstrate a new one. If a demonstra¬ 
tional system creates complex proce¬ 


dures, however, this will be inappropri¬ 
ate. 

One idea is to have the system replay 
the demonstration like a movie, show¬ 
ing the actions that the user performed 
one at a time. The user can stop the 
replay at any point to specify differ¬ 
ences. However, the user’s edits may 
invalidate the rest of the procedure, so 
the system will need safeguards for re¬ 
plays after edits. 

In some situations, the procedure will 
have potentially damaging side effects 
(such as deleting files), so a naive replay 
is not appropriate. Therefore, some op¬ 
erations will have to be simulated or 
not carried out. Another idea is to cre¬ 
ate a graphical presentation of the pro¬ 
cedures and thereby use the techniques 
of visual languages for editing. In gen¬ 
eral, editing in demonstrational inter¬ 
faces is an area that needs significant 
further study. 


D emonstrational techniques can 
substantially improve a wide 
class of user interfaces and ap¬ 
plications by allowing more operations 
to be “direct.” Adding the guessing of 
generalizations from users’ actions can 
further enhance the power and ease of 
use of demonstrational interfaces. These 
techniques can also make the user inter¬ 
faces more powerful and exciting with¬ 
out increasing their complexity. More 
research is needed, however, to solve 
the remaining problems and to conclu¬ 
sively show that demonstrational inter¬ 
faces are viable and easy to use. Never¬ 
theless, I believe that this exciting 
technology will be an important step 
beyond the direct-manipulation inter¬ 
faces of today. ■ 
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Call for Papers 

14th International Conference on 
Applications and Theory of Petri Nets 

Bismarck Hotel, Chicago, June 21 - 25,1993 

The International Conference (formerly called the 
European Workshop) on Applications and Theory of 
Petri Nets has been held annually since 1980 and 
provides a forum for discussing progress in the 
applications and theory of Petri nets. An important 
part of this conference is the two days of tutorials 
covering both introductory and advanced topics, 
including lectures given by Dr. Carl Adam Petri, the 
founder of Petri nets. Petri Nets '93 / Chicago will 
mark the first time that this important conference is 
being held in the U.S. 

Topics cover all aspects of applications and theory on 
Petri nets. 

Submit eight copies of papers of maximum length 20 
pages by Nov. 16,1992 to the Program Committee 
Chair: 

Prof. Marco Ajmone-Marsan 
Dipartimento di Elettronica 
Politecnico di Torino 
Corso Duca degli Abruzzi 24 
1-10129 Torino, ITALY 
E-mail: ajmone@itopoli.bitnet 
Fax: +39 11 564 4099 

Each paper must clearly state the problem being 
addressed, the goals of the work, the results achieved, 
and the relation to other work; and should be in such 
a form that it can be immediately included in the 
proceedings without major revisions. The conference 
proceedings will be published by Springer-Verlag. 

Petri Nets '93 / Chicago will be held in cooperation 
with the IEEE Computer Society and organized by 
the University of Illinois at Chicago (UIC), with the 
assistance of Meta Software Corp. For information 
regarding the conference, contact Organizing 
Committee Co-Chair: T. Murata or S. M. Shatz, 
EECS Dept, (m/c 154), Univ. of Illinois, Chicago, IL 
60680-4348 USA. E-mail: pn93@bert.eecs.uic.edu. 

Important Dates: 

Submit papers by: Nov. 16,1992 
Acceptances sent: Feb. 22,1993 
Final papers due: April 1,1993 
Tutorials: June 21 - 22,1993 
Conference: June 23 - 25,1993 

In Cooperation with the IEEE Computer Society 
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Board elects not to gamble on economic turnaround 


Guylaine M. Pollock 

Financial issues were a main focus 
of the IEEE Computer Society Board 
of Governors meeting June 5 in New 
Orleans. Despite sound fiscal manage¬ 
ment, including extensive budget cut¬ 
backs, conservative forecasting, and 
close monitoring of all activities to 
offset the impact of the world econo¬ 
my and market, the society’s liquid re¬ 
serves have continued to decline. (See 
the Computer Society treasurer’s mes¬ 
sage and the auditor’s report on pages 
5-9 of this issue.) The board chose to 
institute a small increase in dues at 
this juncture rather than wait for the 
economic situation to become critical, 
thereby forcing a more substantial 
dues increase later. 

The board determined that addi¬ 
tional budget cuts are not possible 
without adversely affecting the quality 
of publications, activities, services, 
and benefits available to members. 
Furthermore, sound fiscal manage¬ 
ment mandates that the society not 
gamble on a swift turnaround in the 
economy to eliminate financial con¬ 
cerns. Consequently, a $3 increase in 
member dues for 1993 will allow the 
society to address the reserves prob¬ 
lem without decreasing the quality of 
existing programs, as well as provide 
seed money for new technical initia¬ 
tives proposed by active volunteers. 

The value of the society’s products 
and services and their importance to 
members was underscored by the ap¬ 
proval of a new magazine, two new 
transactions, and a new technical com¬ 
mittee. 

The board approved Vice President 
for Technical Activities Joseph 
Boykin’s motion for the creation of a 
Technical Committee on Parallel Pro¬ 
cessing. The new group brings the to¬ 
tal number of active technical com¬ 
mittees to 27. 

Publications. The board approved a 
proposal for a new magazine to be en¬ 
titled IEEE Parallel and Distributed 
Technology: Systems and Applica¬ 
tions , which will begin publication in 
the first quarter of 1993. The maga¬ 
zine will be a companion to the soci¬ 
ety’s research-oriented IEEE Trans¬ 


actions on Parallel and Distributed 
Systems. 

Two new transactions are also 
scheduled to debut in the first quarter 
of 1993. IEEE Transactions on Net¬ 
working will be published six times a 
year, in partnership with the IEEE 
Communications Society and the 
ACM. IEEE Transactions on VLSI 
will be published quarterly, in part¬ 
nership with the IEEE Circuits and 
Systems Society and the IEEE Solid 
State Circuits Council. 

Upon recommendation of the Pub¬ 
lications Board, the Board of Gover¬ 
nors consented to the following ap¬ 
pointments by President Bruce D. 
Shriver. Ted G. Lewis will succeed 
Jon T. Butler as editor-in-chief of 
Computer, and Benjamin W. Wah will 
be the new editor-in-chief of IEEE 
Transactions on Knowledge and Data 
Engineering, succeeding C.V. Ra- 
mamoorthy. In addition, the following 
editors-in-chief were reappointed to 
second two-year terms: 

• Dante Del Corso, IEEE Micro-, 

• Peter R. Wilson, IEEE Computer 
Graphics and Applications', 


Ted G. Lewis, professor of computer 
science at Oregon State University, 
will bring experience as a former ed- 
itor-in-chief of IEEE Software to his 
new position as Computer’s editor- 
in-chief beginning January 1. 


• Carl K. Chang, IEEE Software-, 

• Earl E. Swartzlander, IEEE 
Transactions on Computers-, and 

• Anil K. Jain, IEEE Transactions 
on Pattern Analysis and Machine 
Intelligence. 

Their terms will begin on January 1, 
1993, and extend through December 
31,1994. 

Publication prices and editorial 
page budgets for 1993 were also set at 
the meeting. Concerned with main¬ 
taining high quality and meeting 
member demand for technical materi¬ 
al, the board increased page budgets 
for all five of the existing transactions 
and for IEEE Software. This increase 
in the quantity of technical material 
delivered to members was accompa¬ 
nied by modest price increases for 
members to partially cover the cost of 
the additional pages; more substantial 
increases for nonmembers (mostly li¬ 
braries) will provide additional income 
to cover increased costs and to help re¬ 
store the society’s liquid reserves. 

Member prices for IEEE Transac¬ 
tions on Computers, IEEE Transac¬ 
tions on Pattern Analysis and Machine 


Benjamin W. Wah will take over as 
editor-in-chief of IEEE Transactions 
on Knowledge and Data Engineering 
on January 1. He is a member of the 
IEEE Computer Society Board of 
Governors. 
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Intelligence , and IEEE Software will 
be increased by $1, and nonmember 
fees will be increased $60, $70, and 
$35 per year, respectively. The page 
budget for IEEE Transactions on 
Computers was set at 1,584 pages. Al¬ 
though this is less than the number of 
pages allotted for 1992, in the long 
term it is an increase of 64 pages over 
the “regular” page budget, since a 
one-year increase in pages was ap¬ 
proved this year to help work down 
the backlog of accepted papers and 
reduce the delay from date of accep¬ 
tance to date of publication. IEEE 
Transactions on Pattern Analysis and 
Machine Intelligence will increase by 
96 pages, and IEEE Software will 
have an additional 32 pages. (Page 
budgets are typically increased in 
numbers that accommodate the most 
cost-efficient press configurations.) 

Subscription prices for IEEE Trans¬ 
actions on Software Engineering will 
increase by $2 for members and $60 
for nonmembers, with an increase of 
112 pages. IEEE Transactions on 
Knowledge and Data Engineering will 
cost an additional $6 and $90 for 
members and nonmembers, respec¬ 
tively, while the page budget will be 
extended 470 pages and the frequency 
increased from quarterly to bimonth¬ 
ly. IEEE Transactions on Parallel and 
Distributed Systems will double its 
publication frequency from bimonthly 
to monthly, with an increase of 664 
editorial pages per year; associated 
price increases will be $7 for members 
and $155 for nonmembers. 

1993 officer and board candidates. 

A slate of 1993 officer and 1993-95 
Board of Governors candidates was 
approved by the board as published in 
Computer (July 1992, p. 93). Addi¬ 
tional nominees may be placed on the 
ballot by the membership at large. 

The requirements for petition candi¬ 
dates appeared in Computer (Febru¬ 
ary 1992, pp. 83-84). 

The board-approved slate of officer 
candidates (one to be elected to each 
office for one year )is as follows: 1993 
president-elect (1994 president, 1995 
past president), Ronald G. Hoelze- 
man and Laurel V. Kaleda; 1993 first 
vice president, Joseph Boykin and 
Gerald L. Engel; 1993 second vice 
president, Fiorenza C. Albert-Howard 
and Anneliese von Mayrhauser. Can¬ 
didates for 1993-95 Board of Gover¬ 
nors (seven to be elected for three 
years) are Hasan S. Alkhatib, Fletcher 
J. Buckley, Doris L. Carver, Elliot J. 
Chikofsky, David M. Choy, JoAnne 
E. DeGroat, Michael J. Flynn, Tadao 
Ichikawa, Mary Jane Irwin, Vincent 


Y. Shen, Grace C.N. Wei, and Akihi- 
ko Yamada. 

Other actions. In other actions, the 
board approved proposed bylaws 
changes brought forward by the 
Press Activities Board and the Stan¬ 
dards Activities Board for initial 
publication in Computer (see below) 
and review by the membership prior 
to a final vote. The proposed chang¬ 
es focus on removing various issues 
from the bylaws and placing them in¬ 
stead in the Policies and Procedures 
Manual to align the bylaws with the 


strategic plan that was previously ap¬ 
proved ( Computer , December 1991, p. 
81). 

The board approved in principle a 
plan presented by Duncan H. Lawrie 
and the Intersociety Cooperation 
Committee for assistance to the 
former USSR and ex-Warsaw Pact 
countries and directed the president 
and executive director to pursue its 
implementation. The board also au¬ 
thorized the president to pursue Com¬ 
puter Society participation and mem¬ 
bership in the IEEE Neural Networks 
Council. 


Society provides awards, judges for science and 
engineering fair 


The IEEE Computer Society con¬ 
tributed to the 43rd International Sci¬ 
ence and Engineering fair by provid¬ 
ing judges and cash awards in the 
computer science category. The fair, 
held in Nashville, Tennessee, May 10- 
16, honored outstanding high school 
students from around the world for 
their scientific expertise. 

A.B. Bonds and Larry Dowdy of 
Vanderbilt University judged the 
computer science entries in the divi¬ 
sion representing professional organi¬ 
zations. Murali R. Varanasi of the 
University of South Florida coordinat¬ 
ed the society’s efforts. 

A $500 award went to Jonobie Dale 
Baker, 15, of Theodore Roosevelt 
High School, Kent, Ohio, for design¬ 
ing and implementing a four-dimen¬ 


sional graphics language. Aaron Sam¬ 
uel Freedman, 17, of Manlius Pebble 
Hill School, DeWitt, New York, won 
a $300 award for an artificial intelli¬ 
gence approach to image analysis. The 
third award, $150, went to Benjamin 
Joseph Raphael, 17, of Paul VI High 
School, Fairfax, Virginia, for simulat¬ 
ed evolution of walking mechanisms. 

Along with the cash awards, each 
winner received a plaque and a one- 
year subscription to Computer. 

In the judging of combined divi¬ 
sions, Baker went on to win first place 
in the Grand Awards competition in 
computer science, sponsored by Mc¬ 
Donnell Douglas. Prizes at this level 
include a trip to the Fourth European 
Community Contest for Young Scien¬ 
tists, to be held in Seville, Spain. 


Bylaws amendments for press, standards 
activities receive first approval 


Bylaws amendments to Articles IX 
and XI were approved for the first 
time at the IEEE Computer Society’s 
Board of Governors meeting June 5, 
1992, in New Orleans. The proposed 
changes are aimed at removing vari¬ 
ous issues from the bylaws and placing 
them instead in the Computer Society 
Policies and Procedures Manual 
(PPM) to align the bylaws with the 
previously approved strategic plan 
(Computer , Dec. 1991, p. 81). 

The current and proposed wording 
of the affected sections are published 
here for member comment before the 
board considers the amendments a 
second time for final adoption. Mem¬ 
ber comments should be sent to James 
H. Aylor, Chair, Constitution and By¬ 
laws Committee, IEEE Computer So¬ 
ciety, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903. 


Article IX. Press Activities 

Current wording: 

Section 1. Press Activities Board 

The Press Activities Board shall be 
responsible for recommending to the 
Board of Governors all policies for 
Computer Society Press activities. It 
shall establish activities and support¬ 
ing operations, and monitor their exe¬ 
cution to assure conformance with ap¬ 
proved policies. It shall be chaired by 
the vice president for press activities, 
and shall consist of the following 
members: the editor-in-chief of the 
Computer Society Press and the chairs 
of the Press Operations Committee, 
the Planning Committee, the New 
Products Committee, the Sales and 
Promotions Committee, and other 
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members appointed by the vice presi¬ 
dent for press activities. The chairs of 
these committees shall be appointed 
by the president on the recommenda¬ 
tion of the vice president for press ac¬ 
tivities. 

Section 2. Standing Committees 

The functions of the standing com¬ 
mittees mentioned in Section 1 shall 
be defined in the Computer Society 
Policies and Procedures Manual 
(PPM). Other standing committees 
may be defined in the PPM. 

Section 3. Editor-in-Chief 

(1) There shall be an editor-in-chief 
appointed. This individual shall report to 
the vice-president for press activities. 

(2) The Press Activities Board shall 
recommend to the president one or 
more candidates for the editor-in- 
chief position. The president, with the 
advice and consent of the Board of 
Governors, shall appoint the editor- 
in-chief for a definite period not to ex¬ 
ceed two years. 

Proposed wording: 

Section 1. Press Activities Board 

The Press Activities Board shall 
formulate the policies for Computer 
Society Press activities. It shall estab¬ 
lish such publishing activities and 
product lines as it shall deem appro¬ 
priate in service of the mission of the 
society and shall monitor the execu¬ 
tion of such programs to assure con¬ 
formance with approved policies. It 
shall be chaired by the vice president 
for press activities, and shall consist of 
the following members: the chairs of 
the standing committees of the Press 
Activities Board, and three to five ad¬ 
ditional members appointed by the 
vice president for press activities. 

Section 2. Standing Committees 

(1) The names and functions of the 
standing committees of the Press Ac¬ 
tivities Board shall be as defined in 
the Computer Society Policies and 
Procedures Manual (PPM). 

(2) The chairs of the standing com¬ 
mittees shall be appointed by the vice 
president for press activities. 

Section 3. Editorial Board(s) 

(1) The names and functions of one 
or more editorial boards shall be as 
defined in the Computer Society Poli¬ 
cies and Procedures Manual (PPM). 


(2) Each editorial board shall be 
chaired by an editor-in-chief as pro¬ 
vided in Section 4 of this article. 

Section 4. Editor-in-Chief Appoint¬ 
ments and Terms 

(1) There shall be an editor-in-chief 
appointed for each CS Press editorial 
board. 

(2) The Press Activities Board shall 
recommend to the president one or 
more candidates for each editor-in- 
chief position at various times as re¬ 
quired. 

(3) The president, with the advice 
and consent of the Board of Gover¬ 
nors, shall appoint the editor-in-chief 
for a definite period not to exceed two 
years. In the case of a new editorial 
board, the initial appointment may be 
for a maximum of three years. 

(4) Editors-in-chief may serve a 
maximum of two consecutive terms in 
a given position. 


Article XI. Standards Activities 

Current wording: 

Section 1. Standards Activities Board 

The Standards Activities Board 
shall be responsible for recommend¬ 
ing to the Board of Governors all pol¬ 
icies and practices with respect to 
standards, and for monitoring all stan¬ 
dards activities to assure conformance 
to approved policies and practices. It 
shall be chaired by the vice president 
for standards, and shall consist of the 
following members: the chairperson of 
the Standards Coordinating Commit¬ 
tee; the chairpersons of other standing 
committees of the Standards Activi¬ 
ties Board; the Computer Society rep¬ 
resentatives to other standards-mak- 
ing organizations, including the IEEE 
Standards Board; one person from 
each sponsor, such as a technical com¬ 
mittee; a representative from the 
Computer Society Technical Activi¬ 
ties Board; and additional members 
appointed by the vice president for 
standards. The president may delegate 
authority for such appointments to 
the vice president. The chairpersons 
of the Standards Coordinating Com¬ 
mittee and the other standing commit¬ 
tees, and the Computer Society repre¬ 
sentatives to other standards-making 
organizations shall be appointed by 
the president with the recommenda¬ 
tion of the vice president for stan¬ 
dards. The president may delegate au¬ 
thority for such appointments to the 
vice president. 


Section 2. Standards Coordinating 
Committee 

The Standards Coordinating Com¬ 
mittee shall monitor the develop¬ 
ment and maintenance of standards, 
and its members shall consist of the 
chairpersons of each standards work¬ 
ing group and standards subcommit¬ 
tee, and other members appointed by 
the vice president for standards with 
the recommendation of the chairper¬ 
son of the Standards Coordinating 
Committee. 

Section 3. Other Standing Commit¬ 
tees 

Other standing committees to ad¬ 
vise and to implement the policies of 
the Standards Activities Board shall 
be defined in the Standards Develop¬ 
ment Guide. 

Proposed wording: 

Section 1. Standards Activities Board 

The Standards Activities Board 
shall formulate the policies and prac¬ 
tices with respect to standards, and 
monitor all standards activities to as¬ 
sure conformance to approved poli¬ 
cies and practices. It shall be chaired 
by the vice president for standards, 
and shall consist of the following 
members: the chairpersons of stand¬ 
ing committees of the Standards Ac¬ 
tivities Board, one representative 
from each sponsor, a representative 
from the Computer Society Techni¬ 
cal Activities Board, and up to seven 
additional members as defined in the 
Computer Society Policies and Proce¬ 
dures Manual (PPM). 

The society representative to the 
IEEE Standards Board shall be an ex 
officio, voting member of the Stan¬ 
dards Activities Board. 

Section 2. Appointments 

The chairpersons of standing com¬ 
mittees of the Standards Activities 
Board, Computer Society representa¬ 
tives to other standards-developing 
organizations, and the society repre¬ 
sentative to the IEEE Standards 
Board shall be appointed by the vice 
president for standards. 

Section 3. Standing Committees 

Standing committees to advise and 
to implement the policies of the 
Standards Activities Board shall be 
defined in the Computer Society Poli¬ 
cies and Procedures Manual (PPM). 
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IEEE, CBEMA take opposing sides on reverse-engineering ruling 


Bob Carlson, Staff Editor 

A US District Court ruling in Cali¬ 
fornia in the case of Sega v. Accolade 
holding that any reproduction of a 
software work, including printing a 
single page of decompiled computer 
code, is copyright infringement has re¬ 
sulted in opposing friend-of-the-court 
briefs by the IEEE and the Computer 
Business Equipment Manufacturers 
Association (CBEMA). 

The ruling — if allowed to stand — 
will stifle innovation and competition 
in the nation’s computer software in¬ 
dustry, says the IEEE, which joined a 
friend-of-the-court brief filed in San 
Francisco by the American Commit¬ 
tee for Interoperable Systems asking 
the US Ninth Circuit Court of Ap¬ 
peals to overturn the ruling. 

Joining CBEMA in a brief support¬ 
ing the ruling are the International 
Anticounterfeiting Coalition, Apple 
Computer, Autodesk, Computer As¬ 
sociates International, Digital Equip¬ 
ment Corp., Intel, IBM, Lotus Devel¬ 
opment, WordPerfect, and Xerox. 

The IEEE’s position is that through 
reverse engineering, independent pro¬ 
ducers frequently improve and extend 
existing software or produce new 
products by deducing the interface 
and operational characteristics of pub¬ 
licly available hardware and software. 
Without decompiling, the underlying 
ideas — which are not subject to 
copyright — cannot be readily ob¬ 
tained from the object code. 

Participants in the CBEMA brief do 
not accept the contention that the 
case is about reverse engineering. 

They claim that it is about copying — 
the making of unauthorized interme¬ 
diate copies in the decompilation of 
computer programs. 

The CBEMA brief holds that the 
practice of making unauthorized cop¬ 
ies in the course of writing a compet¬ 
ing work is inconsistent with fair use. 
“If the court were to hold otherwise 
... it would create a special exception 
for computer programs under the 
Copyright Act, justified by neither the 
language nor the history of our copy¬ 
right law. 

“Such an exception threatens the 
progress and competitiveness of the 


US software industry.... If the cre¬ 
ative efforts of innovative software 
developers can be appropriated so 
easily, the incentives to invest those 
creative efforts, and the resources to 
support those efforts, will diminish.” 

Arvid G. Larson, a vice president of 
the IEEE and head of IEEE-US Ac¬ 
tivities, says, “The disassembly of com¬ 
puter code for study, whether or not 
commercially motivated, is necessary 
for technological progress in software 
engineering. Such disassembly and 
study cannot be carried out without to 
some extent ‘fixing’ the code, or a de¬ 
rivative-work version of it, in a ‘copy.’ 

“We do not believe the courts 
should use sanctions of the copyright 
law or trademark law to help comput¬ 
er equipment manufacturers lock ‘un- 


Finalists have been selected in the 
1992 Gordon Bell Prize competition 
for significant achievement in the ap¬ 
plication of parallel processing to 
practical scientific and engineering 
problems. Bell, a former National Sci¬ 
ence Foundation division director, 
now an independent consultant, is of¬ 
fering the prizes to spur the transition 
of parallel processing from computer 
science research to useful applica¬ 
tions. 

“The high quality of the entries 
made the selection of finalists particu- 


Gordon Bell, designer of more than 
50 computer systems, was awarded the 
IEEE John von Neumann Medal for in¬ 
novative contributions to computer archi¬ 
tecture and design at an annual IEEE 
honors ceremony in Boston May 10. 

Bell designed the first minicomputers 
and time-sharing computers at Digital 
Equipment Corp. and led development 
of the company’s VAX minicomputers. 
His other achievements include start¬ 
ups at Encore Computer, where he was 
responsible for one of the first multiple 
microprocessors, and at Ardent Corn- 


authorized’ software out of the equip¬ 
ment they sell to the public.” 

If US courts put a stop to reverse 
engineering, competitive products 
would still be developed overseas and 
imported for sale in this country, Lar¬ 
son warned. This would further weak¬ 
en the US’s ability to compete in 
world markets. 

Washington, D.C.-area patent and 
copyright attorney Richard H. Stern, 
who specializes in computer and high- 
tech issues, strongly supports the 
IEEE’s position. He says court deci¬ 
sions like the one in question here oc¬ 
cur when the courts initially lack tech¬ 
nical input, get the wrong input, or are 
misled by counsel. He expects to see 
the case argued late this month with a 
decision possibly in the fall. 


larly difficult this year,” said Alan 
Karp, Gordon Bell Prize administra¬ 
tor. “Although the performance of the 
applications submitted did not reach 
the spectacular levels of last year’s en¬ 
tries, the judges felt that all the en¬ 
tries significantly advanced the state 
of the art in parallel processing.” 

Last year’s winning team in the 
price/performance category computed 
the electronic structure of a high-tem- 
perature superconductor on a 128- 
node Intel iPSC/860 at a price/perfor¬ 
mance rate of 840 million floating- 


puter, where he built the first graphics 
supercomputer. 

A director of several companies and 
a founder of the Computer Museum in 
Boston, Bell has received many priz¬ 
es. In 1991, President Bush awarded 
him the National Medal of Technology 
“for his continuing intellectual and in¬ 
dustrial achievements in the field of 
computer design, and for his leading 
role in establishing cost-effective, 
powerful computers that serve as a 
significant tool for engineering, sci¬ 
ence, and industry.” 


Finalists selected for 1992 Gordon Bell Prizes 


Bell receives IEEE John von Neumann Medal 
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point operations per second per mil¬ 
lion dollars. In the compiler parallel¬ 
ization category, the winning team last 
year achieved a speedup of more than 
1,800 and ran at over 1.5 billion float¬ 
ing-point operations per second on a 
Connection Machine with 2,048 float¬ 
ing-point processors. 

This year’s lower-than-expected 
performance was due primarily to the 
fact that the entrants solved harder 
problems than those in previous years, 
Karp explained. 

The 1992 finalists are 

• Tom Cwik and Jean Patterson of 
the Jet Propulsion Laboratory and 
David Scott of Intel Corporation for 
“Electromagnetic Scattering Calcula¬ 
tions on the Intel Touchstone Delta.” 

• Anton Gunzinger, Urs Muller, 
Walter Scott, Bernhard Baumle, Peter 
Kohler, Florian Miiller-Plathe, Wil¬ 
fred F. van Gunsteren, and Walter 
Gugenbuhl of the Swiss Federal Insti¬ 
tute of Technology for “The Music 
System (Multi-Signal Processor Sys¬ 
tem with Intelligent Communica¬ 
tion).” 

• Mark T. Jones and Paul E. Plass- 
man of the Argonne National Labora¬ 
tory for “Solution of Large, Sparse 
Systems of Linear Equations in Mas¬ 
sively Parallel Applications.” 

• Hisao Nakanishi and Vernon 
Rego of Purdue University and Vaidy 
Sunderam of Emory University for 
“Superconcurrent Simulation of Poly¬ 
mer Chains on Heterogeneous Net¬ 
works.” 

• Michael S. Warren of the Los 
Alamos National Laboratory and 
John K. Salmon of the California In¬ 
stitute of Technology for “ Astrophysi- 
cal N-Body Simulations at 5.4 Gf/s.” 

The finalists have been invited to 
present their work at a special session 
during Supercomputing 92, November 
16-20, in Minneapolis, Minnesota. 

Two prizes of $1,000 each will be pre¬ 
sented. 

The two winners will be chosen 
from entries submitted in three cate¬ 
gories: performance, in which the sub¬ 
mitted program must be shown to run 
faster than any other comparable en¬ 
gineering or scientific application; 
price/performance, in which the en¬ 
trant must show that the performance 
of the application divided by the list 
price of the smallest system needed to 
achieve the reported performance is 
better than that of any other entry; 
and compiler parallelization, in which 
judges look for the combination of 
compiler and application that gener¬ 
ates the greatest speedup. 


Jain wins Computer Press Award for how-to book 


The Art of Computer Systems Per¬ 
formance Analysis by Raj Jain was se¬ 
lected as the best advanced how-to 
book on systems in this year’s Com¬ 
puter Press Awards competition. The 
book, published by John Wiley and 
Sons, has received more than a hun¬ 
dred positive reviews in magazines 
worldwide and has been adopted as a 
textbook in numerous universities, ac¬ 
cording to Digital Equipment Corp., 
where Jain is a senior consulting engi¬ 
neer in networking architecture and 
performance. 

Judges evaluated the submissions 
for creativity, presentation, clarity, ac¬ 
curacy, and significance to the respec¬ 
tive audiences. In her citation for the 
award, judge Ann Lent, managing edi¬ 
tor of Byte , said, “The subject of sys¬ 
tems performance is covered from 
start to finish in a very accessible 


manner. Dr. Jain has taken tough ma¬ 
terial and made it accessible.” 

Jain holds a PhD from Harvard 
University and has taught graduate 
courses in performance analysis at the 
Massachusetts Institute of Technolo¬ 
gy. He serves on the editorial adviso¬ 
ry boards of Computer Communica¬ 
tions and the Journal of High-Speed 
Networks, and is vice chair of ACM’s 
Special-Interest Group on Data 
Communication. In addition, he is 
an ACM lecturer for 1992, a senior 
member of the IEEE, and a long¬ 
time member of the IEEE Computer 
Society. 

The Computer Press Awards, co¬ 
sponsored by Citizen America Corp. 
and the Computer Press Association, 
honor outstanding work by journalists 
and authors covering the computer in¬ 
dustry. 


Report assesses scope and direction of computer 
science and technology 


“Although academic computer sci¬ 
ence and engineering has enjoyed re¬ 
markable success in the last several 
decades, the ways of the past will not 
necessarily lead to success in the fu¬ 
ture,” states a report issued July 13 
by the National Research Council/ 
National Academy of Sciences. 

While federal support for computer 
science and engineering (CS&E) re¬ 
search has been critical in recent 
years, growth in funding has not kept 
pace with the growing need for a sci¬ 
ence base to create, control, and ex¬ 
ploit the potential of ever more pow¬ 
erful computer systems, the report 
says. “Nor has funding kept pace with 
the growth in the number of academic 
computer science and engineering re¬ 
searchers; in the academic communi¬ 
ty, the ratio of funding per researcher 
has dropped by over 20 percent since 
1985.” 

Major judgments and priorities. 

Created at the direction of the Com¬ 
puter Science and Telecommunica¬ 
tions Board, the Committee to Assess 
the Scope and Direction of Computer 
Science and Technology made several 
judgments that guided its work. First, 
although the field is relatively new as 
an organized and independent intel¬ 
lectual discipline, it has established a 
unique paradigm of scientific inquiry 
that is applicable to a wide variety of 
problems. Thus, computer science and 
engineering can be an engine of 


progress and conceptual change in 
other problem domains. 

Second, within this field, the tradi¬ 
tional separation of basic research, 
applied research, and development is 
dubious. Because of the way CS&E 
research is practiced, distinctions be¬ 
tween basic and applied research are 
especially artificial, since both call for 
the exercise of the same scientific and 
engineering judgment, creativity, skill, 
and talent. 

Third, the growing ubiquity of com¬ 
puting places a premium on the larg¬ 
est possible diffusion of expertise. It is 
imperative that undergraduate CS&E 
education — the primary vehicle for 
such diffusion — reflect the best 
knowledge and insight the field has to 
offer. 

On the basis of these judgments, the 
committee cited the following priori¬ 
ties: 

• Sustain the core effort that creates 
the theoretical and experimental 
science base. 

• Broaden the field’s self-concept so 
that it can avoid becoming in¬ 
creasingly irrelevant to computing 
practice. 

• Improve undergraduate education 
because its quality is inextricably 
tied to the state of computing 
practice in all sectors of society. 

Core subfields. The core subfields 
listed in Table 1 constitute a future re- 
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Table 1. Importance of computer science and engineering core subfields to selected applications. 




Application 


Core Subfield 

Global Change 
Research 

Computational 

Biology 

Commercial 

Computing 

Electronic 

Library 

Multiple processors 

Very important 

Central 

Important 

Very important 

Data communications 
and networking 

Central 

Important 

Central 

Central 

Software engineering 

Important 

Very important 

Central 

Important 

Information storage 
and management 

Central 

Very important 

Very important 

Central 

Reliability 

Very important 

Important 

Very important 

Important 

User interfaces 

Very important 

Very important 

Central 

Central 


search agenda for CS&E. They can 
both enrich and be enriched by the se¬ 
lected application domains. These 
core subfields correspond to areas in 
which major qualitative and quantita¬ 
tive changes of scale are expected. 
Understanding and managing these 


changes of scale will pose many fun¬ 
damental problems in CS&E, and us¬ 
ing these changes of scale properly 
will result in more powerful computer 
systems that will have profound ef¬ 
fects on all areas of human endeavor, 
the report stated. 


Report now available. The com¬ 
plete report, Computing the Future — 
A Broader Agenda for Computer Sci¬ 
ence and Engineering, is available for 
$24.95 from the National Academy 
Press, PO Box 285, Washington, DC 
20055, phone (800) 624-6242. 


KUWAIT UNIVERSITY 

The department of Electrical & Computer Engi¬ 
neering at Kuwait University invites applications 
for faculty positions beginning September 1992 
and February 1993. Duties include teaching 
courses at undergraduate and graduate levels. 
Specialities required are: 

• Compiler Design 

• Software Engineering 

• Design Automation of Digital Systems 

• Computer Networks 

• Image Processing 

• Communications, Power and Machines, 
Control, Electronics 

The successful candidate must have a Ph.D. in 
Electrical or Computer Engineering. Application 
forms and additional information may be obtained 
from: 

Embassy of the State of Kuwait 
Kuwait University Office 
3500 International Drive, N.W. 

Washington, D.C. 20008 
Tel: 202-363-8055 

Completed applications must be returned to: 

Office of the Dean 

College of Engineering & Petroleum 

Kuwait University 

P.O. Box 5969 Safat, 13060 Kuwait 
Fax No. (965)4811772 
Tel. No. (965)4817175 


University of Minnesota, Twin Cities 

Head of the Department of Computer Science 

The University of Minnesota, Twin Cities, invites applications 
and nominations for the position of Head of the Department of 
Computer Science. The Head, who also holds a tenure-rank position 
of Professor, is responsible for providing leadership and helping to 
focus the intellectual, research, and educational directions of the 
department, for representing the department’s interests on campus 
and to external constituencies, for planning and overseeing the de¬ 
velopment of its academic programs and its research activities, and 
for the administration of the department. The department Head, as 
a faculty member, is to engage in the educational and research ac¬ 
tivities of this unit. The Head reports to the Dean of the Institute of 
Technology. 

The Department of Computer Science is one of eleven depart¬ 
ments that comprise the Institute of Technology. It currently has a 
faculty of 28 tenure and tenure track members and a budget of 
approximately $4.7 million. The Minneapolis-Saint Paul area is a 
major center for high technology and the computer industry. Faculty 
in the Department of Computer Science have access to outstanding 
computer facilities both within the department and at several high 
performance computing centers on campus. These facilities include 
a Cray-2, a Cray X-MP, a Connection Machine model CM-200, a 
Connection Machine model CM-5, and a 16-processor Ncube-2. 

Applications and nominations must be received by November 
20,1992, and should be sent to: 

Chair, Head Search Committee 
Department of Computer Science 
University of Minnesota 
4-192 EE/CSci Building 
200 Union St., S.E. 

Minneapolis, MN 55455 

The University of Minnesota is an equal opportunity educator and employer. 
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PRODUCT REVIEWS 

Send review submissions to Product Reviews Editor: J.M. Jagadeesh, College of Pharmacy, 500 West 12th Avenue, Ohio State University, Columbus, OH 43210 


What light through yonder Windows 3.1? 


Now that all the hoopla has died 
down, the decision to go with Win¬ 
dows 3.1 can consider need rather 
than hyperbole. Frankly, if you aren’t 
interested in the graphical user inter¬ 
face that Windows offers, or if you’ve 
made up your mind to go with OS/2 
version 2.0, you might as well stop 
reading right now. The purpose of 
this review is not to tell you to switch 
to Windows, but rather to tell you 
what has changed and why an upgrade 
is worthwhile (if not mandatory). Af¬ 
ter all, convincing someone that a spe¬ 
cific GUI is the way to go is much 
akin to suggesting a proper political 
or religious preference. So just be¬ 
cause I am a daily user of Windows 
doesn’t mean that I feel others should 
be; but you who are committed Win¬ 
dows users, or leaning in that direc¬ 
tion, read on. 

Polishing up Windows 

To run and enjoy Windows you will 
need a capable machine. My system is 
a PC Genius 486/33 with 8 Mbytes of 
memory and 210 Mbytes of disk 
space. I have an ATI Ultra graphics 
adapter and a NEC 4D MultiSynch 
16-inch display. Its performance has 
been excellent under version 3.0 of 
Windows and is even better under 3.1. 

Ease of use. This new version in¬ 
stalls more automatically, with the 
software detecting the hardware plat¬ 
form and warning of installed soft¬ 
ware (like TSRs) known to cause 
problems. The file, program, and print 
managers have been improved as well, 
although I must admit I prefer Nor¬ 
ton’s Desktop for Windows and use it 
as the shell in place of Windows file 
and program managers. Thus, while 
you can use the drag-and-drop feature 
of version 3.1 to print a file or start an 
application, and to associate file types 
with specific applications, I use Nor¬ 
ton’s enhanced functionality. 

Speed. What I really like is that 
Windows is noticeably faster — from 


booting up to loading programs to 
moving files. The claimed numbers 
range from 1.3 to 10 times. (Although 
I did not verify the numbers, I defi¬ 
nitely perceived the change.) The lat¬ 
est version of SmartDRV is also faster 
and caches writes as well as reads. 
Display and printer drivers have im¬ 
proved, but during the change from 
3.0 to 3.1,1 upgraded my display 
adapter and can’t determine how 
much of the increased performance is 
due to the new board or to the soft¬ 
ware. I did find that my QMS Post¬ 
Script printer runs slower when re¬ 
ceiving bitmapped data, but I haven’t 
received the final 3.1 driver from 
QMS (only the interim release) so 
things may improve. 

Reliability. Like many of you, I was 
darned tired of receiving “unrecover¬ 
able application error” messages that 
did strange things and required me to 
either restart Windows 3.0 or proceed 
with the uneasy feeling that bad things 
were going to happen. In version 3.1, 
Microsoft corrected this situation by 
adding parameter verification for ap¬ 
plications, providing more informa¬ 
tion and procedures for recovering 
from applications errors, and offering 
application reboot options (including 
closing the application, continuing, or 
rebooting either the offending appli¬ 
cation or Windows itself) to prevent a 
system crash or loss of data. Now 
when the Windows application stops 
responding to the system, you can do 
something reasonable about it without 
having to restart your computer! 

Another important factor for me 
was running out of “system resourc¬ 
es.” Due to the way Microsoft had al¬ 
located and utilized this data space, it 
was not uncommon to have lots of 
real and swapping space and yet — af¬ 
ter opening just a few windows — to 
be told to close them before opening 
up new ones. Now, in version 3.1, my 
desktop is starting to be cluttered with 
windows that I leave open as icons so 
that I don’t have to close and later re¬ 
open them in my daily work routine. 
True, some of my graphics applica¬ 


tions still seem to run out of memory 
(or even disk space), but I’m not sure 
this is Windows’ fault. This problem 
may well disappear when the applica¬ 
tions are rewritten for the latest version. 

Innovations. Windows 3.1 includes 
object linking and embedding, True¬ 
Type, better MS-DOS support, audio 
services and media device support for 
multimedia, and laptop/pen comput¬ 
ing features. It may surprise some of 
you, but the only feature in the list I 
care about is the MS-DOS support be¬ 
cause it lets me run a VGA-based ap¬ 
plication in a Window and use the 
mouse without having to go to a full¬ 
screen window. Lumped in with this is 
support for 32-bit disk accessing, 
which works fine if you have a disk 
controller that is fully Western Digital 
1003-compatible. I have an IDE drive 
and experienced no problem. But the 
sidebar on page 82 describes what can 
happen if you have a SCSI drive. 

For me, TrueType is a religious is¬ 
sue as well. I used both Adobe Type 
Manager and MoreFonts with Win¬ 
dows 3.0, and was very pleased with 
the results. TrueType is bundled with 
Windows 3.1 and there’s no reason 
not to use it, unless you are like me 
and find the older fonts more appeal¬ 
ing. Maybe it’s age and tired eyes, but 
it took me a while to accept TrueType 
enough to remove Adobe Type Man¬ 
ager and save the disk space. (You 
can have both, of course, but I don’t 
think you really need them.) 

Where I really see the difference is 
when I switch to my WinFax Pro sys¬ 
tem to send a fax from my word pro¬ 
cessor. Because I have a QMS Post¬ 
Script printer, I get one set of fonts 
when I print a page and another when 
I fax it. The differences are signifi¬ 
cant. I don’t remember this problem 
with my old font managers. 

By the way, if you were using More- 
Fonts with Windows 3.0, you will need 
an upgrade to use it with version 3.1. 1 
called MicroLogic, which rushed a 
new disk to me for free. I don’t know 
exactly what their upgrade pricing is, 
but it’s well worth it if you want some 
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fonts with pizzazz to dress up your 
printed output. 

Summary. Windows is a solid per¬ 
former that greatly increases user per¬ 
formance through a desktop that lets 
you rapidly switch between applica¬ 
tions, sharing files and data. It works 
well with most networks. (I use LAN¬ 
tastic from Artisoft.) The bottom line 
for Windows users is: If you haven’t 
upgraded, you ought to immediately. 
You can do so for as little as $50, 
which is a steal. For those of you who 
haven’t given it a try, you can hardly 
lose with a retail price of $149. 

Readers can contact Microsoft 
Corp. at 1 Microsoft Way, Redmond, 
WA 98052-6399; (800) 426-9400; or 
circle Reader Service Number 21. 

— Richard Eckhouse, University of 
Massachusetts at Boston 


The new and very 
improved version 

It is often the little things that make 
a new version of a familiar piece of 
software most valuable. For example, 
while Microsoft has made many signif¬ 
icant additions to Excel Version 4.0,1 
am most pleased by capabilities that 
let me customize the toolbar, scale the 
text size to make my spreadsheet print 
on a single page, and set up work¬ 
books of bound files. Thus, I can for¬ 
go the improvements in chart types or 
and the addition of slide show capabil¬ 
ities because I don’t use them with 
regularity. But being able to copy my 
cells easily and center text with fewer 
mouse ticks by using shortcut menus 
really makes me a happy camper. 

To be fair, let me list the many oth¬ 
er new features in version 4.0. Autofill 


Problems can occur when installing Windows 3.1 


Although other reviewers had no 
problems getting Windows up and run¬ 
ning, I did. Two things about my sys¬ 
tem caused trouble. 

During installation, Setup reported 
that it could not install a permanent 
swapfile. A call to Microsoft’s technical 
support quickly identified the problem. 
Windows cannot build a permanent 
swapfile on a disk that has a Unix par¬ 
tition. Once I removed the partition, 
created a single DOS partition, and 
performed a DOS format, Setup creat¬ 
ed the swapfile. Hopefully, Microsoft 
will fix this, but why do I get a feeling it 
won't be until the introduction of the 
NT operating system? 

Anyway, the swapfile was the least 
baffling of the two problems. The other 
involved SCSI adapters. Several re¬ 
viewers have SCSI disks installed on 
their systems. One has an Always 
Technology IN-2000 SCSI adapter, an¬ 
other has an Adaptec 1740A, and I 
started out with an Adaptec 1542B. 

I installed Windows on the Comtrade 
33-MHz 486 that I reviewed last 
month, but I couldn’t start it up in en¬ 
hanced mode. When I started Win¬ 
dows in standard mode, the 386 en¬ 
hanced icon didn't even appear in the 
control panel window. I went through 
all the trouble-shooting tips described 
in the Windows installation manual, 
but they didn’t help, so I called Mi¬ 
crosoft technical support. I was ad¬ 
vised that I needed a driver from 
Adaptec for Windows to work properly 
with the 1542B. Unfortunately, Adapt¬ 
ec didn’t have the driver ready. 

After finding out that one reviewer 
was using the IN-2000 successfully, I 
called Always Technology to see why 
its adapter worked. They sent me an 


IN-2000 and, sure enough, installing it 
did the trick. They also sent a newslet¬ 
ter that helped explain the problem. 
SCSI adapters use either bus master¬ 
ing or programmed I/O (PIO) to inter¬ 
face to a PC host bus. If your SCSI 
adapter uses PIO, like the IN-2000 and 
the Adaptec 1740A, Windows will have 
no problems. But if your adapter uses 
bus mastering, like my Adaptec 
1542B, you will have problems. 

A bus master adapter uses direct- 
memory access, and since mother¬ 
board DMA controllers usually don’t 
support transfer rates above 1 Mbyte/ 
s, most bus master adapters have on¬ 
board high-speed DMA controllers (re¬ 
ferred to as first-party DMA). The prob¬ 
lem occurs because in order to be 
addressed as memory, the DMA con¬ 
troller must reside in the memory swap 
space, which is also used by memory 
managers such as the one used in 
Windows. Adapters that use PIO are 
managed by the PC microprocessor, 
which uses CPU I/O instructions to 
transfer data directly to and from the 
bus. In particular, there is no memory 
conflict. 

By the way, Always Technology 
makes both kinds of adapters; the 
newsletter explains when to get a PIO 
adapter and when to get a bus-master¬ 
ing adapter. Generally, PIO is faster 
for systems with an AT (ISA) bus run¬ 
ning DOS. But for systems with a 32- 
bit EISA bus running OS/2 or eventual¬ 
ly Windows NT, a bus-mastering 
adapter may be better. For more de¬ 
tails, call Always Technology at (818) 
597-1400. 

— T.L. (Frank) Pappas, Aweb 
Software Technology 


recognizes trends in your data and in¬ 
telligently extends those trends as 
you drag your mouse across columns 
or down rows. Drag-and-drop is a 
good way to cut, copy, move, and 
paste data. Wizard on-line assistants 
walk you through complex tasks, such 
as chart creation, and help you learn 
the new features as you work. Work¬ 
books replace worksheets and offer a 
table of contents to access, organize, 
and share files. The view manager 
saves your display so you can recall 
different views of the same worksheet. 

Crosstabs is useful for creating 
summary tables from databases; 
CrosstabWizard, for analyzing re¬ 
sults. Autoformat applies one of 14 
formats to your worksheet with one 
mouse click. ChartWizard walks you 
through the steps to create a chart 
complete with titles, legends, and full 
formatting. The scenario manager 
does a “what-if” analysis by creating 
and saving separate summary reports 
based on different scenarios. The re¬ 
port manager lets users define differ¬ 
ent sections of their worksheet to 
print as one report. The solver han¬ 
dles integer programming up to five 
times faster than in Excel 4.0. A 
zoom feature reduces or enlarges a 
worksheet view from 10 to 400 per¬ 
cent. Slide show lets you create a 
desktop presentation as in Mi¬ 
crosoft’s PowerPoint. For Lotus 1-2-3 
users there’s a new macro interpreter 
that lets them run their macros un¬ 
modified in Excel. And, finally, a 
spelling checker has been added. 

What I have said is related not only 
to the PC version of Excel. Microsoft 
has long promised to build a common 
set of tools, like Excel and Word, for 
both the PC and the Mac platforms. 

In the case of Excel 4.0, they have re¬ 
leased the same software with a com¬ 
mon manual. Thus, what I describe 
for the PC should apply equally to 
the Mac. My hat is off to Microsoft 
for carrying off its promise. 

The pricing for Excel for Windows 
or for the Macintosh is $495, with an 
upgrade price of $99 for users of pre¬ 
vious versions. Lotus 1-2-3 or Bor¬ 
land Quattro Pro users get a special 
$129 price to convert to Excel 4.0. 

Microsoft had two main goals for 
Excel version 4.0: easier use and 
greater functionality. In my mind, 
they outdid themselves. 

Readers can contact Microsoft 
Corp. at 1 Microsoft Way, Redmond, 
WA 98052-6399; (800) 426-9400; or 
circle Reader Service Number 22. 

— Richard Eckhouse, University of 
Massachusetts at Boston 
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Reference books for the new Windows user 


Microsoft Press sent me a wide se¬ 
lection of books germane to my Win¬ 
dows reviews: 

• Word for Windows Companion by 
Mark Crane, M. David Stone, and 
Alfred Poor; 

• Windows 3.1 Companion by Lori 
Lorenz and R. Michael O’Mara with 
Russell Borland; 

• Learning & Running Windows 3.1 
and Running Windows 3.1 by Craig 
Stinson; 

• A Concise Guide to Microsoft 
Windows 3.1 by Kris Jamsa; and 

• Running Microsoft Excel 4 by 
Douglas Cobb and Judy Nynhier with 
Craig Stinson, Mark Dodge, and 
Chris Kinata. 

Word for Windows Companion 
comes from the Cobb Group, which 
is well respected for its excellent 
newsletters on popular software. In 
this case, the authors have put to¬ 
gether a book with over 800 pages in 
five sections: (1) Getting Started, (2) 
Word Basics, (3) Advanced Word, (4) 
Special Needs, and (5) Customizing 
Word. While this may seem impos¬ 
ing, it's really not. You can proceed 
through the initial material to get you 
started and then refer to the later 
chapters as you become more famil¬ 
iar with Word for Windows. 

Because I’m not a Word for Win¬ 
dows user, a book like this is much 
more helpful to me than plunging into 
the manuals. The book’s clear, con¬ 
cise style — with lots of explanations, 
advice, and figures — makes using 
this complex software much easier. 
This is the second edition and it ad¬ 
dresses features added in version 2, 
such as object linking and embed¬ 
ding, customizing the toolbar, and 
creating form letters with envelopes 
by using the print merge helper. 

At $29.95, Word for Windows Com¬ 
panion (ISBN 1-55615-450-X) is a 


bargain that you can continue to use as 
your sophistication grows. 

The second companion book is also 
from the Cobb Group. It too is massive, 
with around 525 pages devoted to the ba¬ 
sics of using Windows and applications 
running under the program manager, as 
well as understanding modes, memory, 
and PIFs. It too is clear and concise, ex¬ 
plaining how things work and how you can 
work efficiently with Windows. One unusu¬ 
al feature is a color section that starts with 
the opening Windows 3.1 logo screen and 
includes displays of the main, control pan¬ 
el, and accessories groups, as well as 
eight of the different color schemes you 
can select for your “personalization” of 
Windows. Another nice touch is reference 
pages at the end that give the keystroke 
and function for such keys as Windows, 
dialog box, menu, cursor movement, edit¬ 
ing, clipboard, and print manager. 

Priced at $27.95, Windows 3.1 Com¬ 
panion (ISBN 1-55615-372-4) is a nice gift 
for a friend just beginning to master Win¬ 
dows or an informative addition to your 
own bookshelf when the Windows manual 
is just not detailed enough. 

Learning & Running Windows 3.1 
(ISBN 1-55615-431-3) is a tutorial geared 
toward the beginning-to-intermediate 
user. The $39.95 price includes the Mi¬ 
crosoft Productivity Pack, a disk-based tu¬ 
torial. While this is a well-written, easy-to- 
read book, I found the boxes containing 
Windows Tips distracting. Like the previ¬ 
ous book, this is a hefty tome, containing 
over 500 pages, 19 chapters, and three 
appendices. However, as one who has 
used Windows for several years now, I did 
not find anything new in the text and 
would recommend this only to the new 
user who finds the manuals insufficient. 

Stinson’s other book, Running Windows 
3.1 (ISBN 1-55615-373-2) is exactly the 
same as his learning and running book 
but does not include the tutorial disk. If 
you don’t need the disk, you can get the 
book alone for $27.95. 

For those wanting “just the facts,” A 


Concise Guide to Microsoft Windows 
3.1 (ISBN 1-55615-470-4) might be a 
better buy at $12.95. Also geared to 
the beginning-to-intermediate user, 
this guide can be used to glean instant 
answers to get Windows running. Top¬ 
ics include the program, file and print 
managers, the task list, and the built- 
in desktop applications. There’s even 
a section on Windows games. So if 
you’re a new user who needs help but 
doesn’t want to be overwhelmed, this 
200-page book might be just the thing. 

My favorite book of the bunch was 
Running Microsoft Excel 4 (ISBN 1 - 
55615-488-7). The reason is that even 
after using Excel for several years, I 
have never felt that I had mastered all 
the features of this wonderful spread¬ 
sheet. In this epic tome, the authors 
(members of the Cobb Group) eradi¬ 
cated that feeling. Their clear and in¬ 
teresting writing style features step- 
by-step tutorials, plentiful examples, 
and well-selected screen illustrations. 

in nearly 900 pages, this book ca¬ 
ters to both beginner and advanced 
users. It goes over worksheets, charts, 
databases, macros, and interfacing 
Excel with other applications. Each 
section started with the basics and 
progressed with sufficient detail to 
make me feel comfortable using the 
advanced features that make Excel so 
powerful. Two appendixes cover tool¬ 
bars and the most valuable keyboard 
shortcuts. 

Offering both depth and breadth, 
Running Microsoft Excel 4 is now my 
primary source of information on Ex¬ 
cel. At $29.95, it is a “best buy” — one 
that I will be using frequently as I con¬ 
tinue to grow as an Excel power user. 

Readers can contact Microsoft 
Press at 1 Microsoft Way, Redmond, 
WA 98052-6399; (206) 882-8080; or 
circle Reader Service Number 23. 

— Richard Eckhouse, University of 
Massachusetts at Boston 


Making things better 

My favorite Windows CAD pro¬ 
gram has been replaced! Not to worry 
— version 2.0 of Drafix Windows 
CAD from Foresight Resources has 
even more of what I liked so much in 
the previous version. From a new user 
interface to an intelligent cursor, this 
release is just great and uses the Win¬ 
dows metaphor more consistently — 
from the new menu structures to the 
CAD edit bar to the clipboard. 

Foresight prides itself on having lis¬ 
tened to what version 1.0 users want¬ 
ed, and rightly so. For example, the 
intelligent cursor now shows shape 
depending on the snap mode (for ex¬ 
ample, to grid point, end point, and 


midpoint), without changing the old 
way of picking the snap setting — 
namely, typing a single letter to 
change modes. Another obvious 
change is code optimization to make 
Drafix Windows CAD 50 to 100 per¬ 
cent faster (badly needed since run¬ 
ning under Windows does come at the 
price of performance). There is also a 
new toolbox that includes 16 icons for 
selecting, drawing, viewing, editing, 
setting snap modes, entering text, di¬ 
mensioning, hatching, transforming, 
and trimming. You click on one to se¬ 
lect the tool or click and hold to pop 
out an additional set of icons within a 
group. For instance, if you click and 
hold the polygons icon, you get to 
choose the polygon type. 


The new CAD edit bar shows geo¬ 
metric information and lets users 
change that information for the last 
item drawn or selected. When an arc 
is selected, the edit bar shows the cen¬ 
ter coordinates, radius, and starting 
and ending angles, any of which can 
be clicked on and changed. Above 
this, but below the menu bar, is the 
status bar, which shows the current 
layer, color, line style, line width, and 
pattern/fill color. Drop-down boxes 
associated with each of these features 
are used to change any value. 

One issue that bothered me in the 
last version and got fixed in this one is 
the size of menus, text, and icons 
when running Windows in a high-res¬ 
olution (1,024 x 768) mode on a 16- 
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inch display (as I do). The options 
menu item now features a preferences 
dialogue box where you can set the 
size of icons and text bars. 

The Drafix Graphics Language 
(DGL) and the new Drafix Macro Ed¬ 
itor let users tailor Drafix Windows. 
These macros can be made into but¬ 
tons or used to replace or supplement 
existing menu commands. The pack¬ 
age includes a great many macros, 
which is helpful since the DGL Pro¬ 
gramming Guide does not come with 
the package and must instead be re¬ 
quested from Foresight Resources. 

The macro language has been en¬ 
hanced from the earlier version to al¬ 
low the export of data using DDE 
techniques from Windows CAD to 
other programs such as Excel, Paint¬ 
brush, or Windows Write. 

As described in my earlier review 
( Computer , Sept. 1990, pp. 107-109), 
Drafix Windows CAD has a good set 
of drawing and editing tools, and a 
particularly strong and flexible set of 
database tools. Up to 60 attributes can 
be attached to each entity — even cal¬ 
culated values such as length or area. 
You can use this information to select 
a combination of geometric, graphical, 
and database attributes that will pick 
out all entities with these qualities 
from a complex drawing. Of course, 
you can also use this information 
when developing a bill of materials, a 
parts list, or even a cost estimate. 

The manual has been completely re¬ 
done. It is better written and put to¬ 
gether. Almost 600 pages, it is divided 
into three parts. The first part intro¬ 
duces the software and hardware fun¬ 
damentals, as well as CAD concepts 
and the user interface. Part two in¬ 
cludes five tutorial chapters from 
drawing to dimensioning to using the 
database. Part three is the technical 
reference. Six appendixes include 
drawing-file conversion, customiza¬ 
tion, and what’s in the general symbol 
libraries. As with any good Windows 
program, there is on-line help as well. 
And for those who use a mouse, the 
mouse pad shows the tool, command, 
and key for many important functions. 

You can get started by using a mul¬ 
tipage slick cardboard Quick-Start 
Tutorial. I received mine both with 
the complete system and in a separate 
demo package. Thus, I would presume 
that you could ask for the demo to try 
Drafix Windows CAD before you 
purchase the full $695 product. (The 
upgrade price is $145.) 

I did find a couple of faults. One 
was part of the demo, where the in¬ 
structions don’t follow the implemen¬ 
tation (in one case a file was not in 


the subdirectory mentioned and in the 
other I could not construct the figure 
as outlined in the text). I also found a 
spurious line or two left around as I 
was creating figures, and it took a re¬ 
draw to remove them. Most annoying, 
and a carryover from the previous 
version, is the system beep when I am 
in a snap mode and want to do some¬ 
thing that doesn’t make sense (like 
use the tangent snap when my entity 
to snap to is a line). I know it’s my 
stupidity, but I’d like a friendlier re¬ 
minder. 

In my last review I concluded that 


Getting it right in more ways 

It’s amazing how your perspective 
can change when you’re reviewing 
software. I started my review of Cal- 
era’s FaxGrabber thinking that this 
was an interesting package that shoots 
for, but slightly misses, its target. Hav¬ 
ing had some trouble getting the sys¬ 
tem set up, I approached the convert¬ 
ed text with an “it’d better be good” 
attitude. The results seemed fair until 
I compared them with my two other 
OCR programs. Neither of them did 
anywhere near so well (each had a 
lower recognition accuracy), and both 
were much slower. Boy, did that 
shake me up and force me to take a 
second look. Here’s what I learned. 

As I said, I had some trouble under¬ 
standing how to set up the software. 
During setup, you are asked a number 
of questions such as the name of your 
fax board (mine wasn’t supported), if 
you want to have FaxGrabber moni¬ 
tor incoming faxes and process them 
automatically, the desired output for¬ 
mat for your processed text (the list 
includes everything from ASCII to 
your favorite word processor), if you 
want to place the processed fax in the 
clipboard queue, if you want to launch 
automatic preview and postview ap¬ 
plications, and some other stuff. 

Well, I checked off everything and 
restarted my system so that Windows 
came up waiting and eager to convert 
an incoming fax. Then I sent myself a 
fax, but nothing happened! The prob¬ 
lem was that I had checked too many 
options and nothing was working. 

Also, FaxGrabber wants to see a 
PCX, TIFF, or DCX file format, 
which I didn’t have with my unsup¬ 
ported board and fax software. 

So I changed some options and 
started again. Voila! Things started to 
happen. First, I converted my incom¬ 
ing fax to PCX format using the view¬ 
er option in WinFax Pro. Shortly, I 
saw the FaxGrabber icon change to 


Drafix Windows CAD was an ideal 
system for me. Since that time I’ve 
had a colleague look at this package 
as well as a non-Windows, high-end 
CAD system. Her “impartial and ob¬ 
jective” comments add up to a prefer¬ 
ence for Drafix Windows CAD. 

Readers can contact Foresight Re¬ 
sources Corp. at 10725 Ambassador 
Dr., Kansas City, MO 64153; (816) 
891-1040; fax (816) 891-8018; or circle 
Reader Service Number 24. 

— Richard Eckhouse, University of 
Massachusetts at Boston 


than one 

show the conversion process was run¬ 
ning (FaxGrabber checks about every 
16 seconds to see if a new file has ap¬ 
peared in its subdirectory). Next, I 
saw the postview queue icon that I 
had clicked on to bring up my word 
processor, Ami Pro. Now I had the 
hang of it, and things looked pretty 
good. Also, I read further in the man¬ 
ual and saw in bold italics: “Impor¬ 
tant: Previewing faxes is in lieu of 
processing them.” That meant 
FaxGrabber would not automatically 
continue processing a fax after pre¬ 
viewing it. 

The purpose of the preview func¬ 
tion is to let me cut off the junk I 
don’t want to have FaxGrabber recog¬ 
nize (you know, that tiny stuff at the 
top or bottom identifying the sender 
and date) and then cut or copy the 
preview image to the Windows clip¬ 
board, which automatically signals 
FaxGrabber to proceed with process¬ 
ing. Okay, okay, I was rushed the first 
time and did not read the manual 
carefully before starting the software. 
But even after reading and rereading 
the manual, I never did get the pre¬ 
view function to work so that Ami Pro 
was called after I copied the text I 
wanted converted to the clipboard. 

My first fax was in fine mode be¬ 
cause I thought that would be an easy 
test. The results were pretty good, 
with only a few incorrectly recognized 
words that were easily picked up by 
my spellchecker. So I next sent a fax 
in standard or low-resolution mode 
(100 x 100 rather than 200 x 100). As 
expected, recognition went down, and 
I found about 24 errors on a full-page 
business letter containing 433 words. 
Not too bad since that represents a 94 
percent recognition rate. But you will 
rarely get better than that, since few 
people send faxes in fine mode, where 
the recognition rate would be higher. 

If you do own an Intel Connection 
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I coprocessor and SatisFaxtion, Com- 
I plete PC Fax 9600, Frecom 96, or 
I CAS-Compatible Fax card, then 
[ FaxGrabber will communicate direct- 
| ly with your board and automatically 
[ start the conversion process. And to 
quote a letter I received from Calera, 

' “The next version of FaxGrabber will 
more tightly integrate support of fax 
boards through WinFax Pro, and oth¬ 
er fax software, as it presently does 
I through SofNet’s Faxlt, thus eliminat- 
[ ing the extra step [of converting the 
received fax to PCX format].” 

Okay, I think Calera has a winner 
I here. You have to understand how 
I difficult it is to convert a fax to text 
| format. FaxGrabber gives you a less 
than perfect, but acceptable conver- 
[ sion. At $149, this software is reason- 
I ably priced and can be used not only 
for faxes but for anything else you 
I choose to scan in. Of course, if you 
f want the real thing, you can upgrade 
| your purchase to WordScan Plus for 
only $295 by using the coupon en- 
I closed with the software. 

Readers can contact Calera Recog- 
[ nition Systems Inc. at 475 Portero 
Ave., Sunnyvale, CA 94086; (408) 
720-8300; fax (408) 720-1330; or circle 
i Reader Service Number 25. 

— Richard Eckhouse, University of 
Massachusetts at Boston 


Logical Document Design 
with Scientific Word 

Scientific Word provides a Win¬ 
dows-based logical layout front-end 
for LaTex, the popular macro package 
for Donald Knuth's typesetting sys¬ 
tem, Tex (frequently typeset as La- 
T E X and T E X). Although promoted 
as a word processor for scientific doc¬ 
uments, most LaTex users should be 
able to employ it in preparing any La¬ 
Tex document. 

Figure 1 illustrates Scientific 
Word’s layout features. It shows the 
beginning of a typical mathematical 
paper that might appear in a journal. 

(I created this document as part of the 
tutorial.) It shows the logical layout of 
the paper, without regard to what the 
printed output will look like. When 
writing a paper, you should only be 
concerned with such issues as identify¬ 
ing section headings, stating theorems, 
providing bibliographic citations, and 
making references to other portions 
of the paper. These have nothing to 
do with the paper’s appearance, which 
varies with the style used by the jour¬ 
nal it will appear in. 


The text line, “Mathematics and 
Text,” and the other two lines in large 
type, are section headings. By default, 
Scientific Word uses blue to display 
section titles. Mathematical symbols 
are displayed in red, as are the frames 
used to show centered formulas. The 
rest of the text is displayed in black. 

The end of the third line contains 
the tag “cite: dunford,” which marks a 
citation to Dunford and Schwartz’ 
classic book Functional Analysis — 
one of the references at the end of the 
paper, where it has the tag “dunford.” 

The end of the second displayed 
equation contains the tag “wave.” The 
next line is one of two places in the 
paper that reference the equation 
through this tag. In the following line, 
the tag “marker: theorems” references 
the section. Finally,“Theoremlmarker: 
existence” introduces a theorem and a 
reference tag for the theorem. 

The style in the tutorial produces a 
two-column page. Section titles are 
bold and centered, but use the same 
typeface and size as the rest of the 
text. Statements of theorems, proposi¬ 
tions, and corollaries are numbered 
and italicized. Title and author lines 
are centered across both columns. 

The style can be altered drastically. 
For example, it can print one column, 
omit a table of contents, or replace 
the form of citation and reference tag 
listings from [1] to [D&S64], 

The icons in the Objects and Tools 
bar that appears after the menu line is 
very simple to use. For example, to 
enter an integral with limits, you just 


click on the integral symbol, click on 
the subscript and superscript objects 
(N and x, respectively). This produces 
two small limit boxes into which you 
can type arbitrarily complex expres¬ 
sions, including symbols from the 
Symbol bar. 

Scientific Word comes with pre¬ 
defined styles for letters, memos, and 
reports, and with article styles for 
many scientific journals — so many 
that you will probably never need to 
know anything about LaTex or Tex, 
unless you want to change the styles 
significantly or create a new one. 

Since Scientific Word produces La¬ 
Tex documents, it includes TurboTex 
from Kinch Computer. The package 
includes a screen previewer and driv¬ 
ers for PostScript and LaserJet print¬ 
ers. You get all of this for $595 list 
and $476 academic. 

The only drawbacks I noticed are 
that Scientific Word supports only La¬ 
Tex and doesn’t seem to have a way 
of integrating other Tex versions. 
However, the TurboTex package is so 
nicely integrated into Windows as a 
stand-alone package that I will proba¬ 
bly switch to Scientific Word and use 
TurboTex directly for my non-LaTex 
needs. If you use Tex and LaTex, you 
should consider doing the same. 

Readers can contact TCI Software 
Research at 1190 Foster Road, Las 
Cruces, NM 88001; (505) 522-4600; or 
circle Reader Service Number 26. 

— T.L. (Frank) Pappas, Aweb 
Software Technology 



Figure 1. Scientific Word screen. 
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Document preparation 
using FrameMaker 

FrameMaker integrates desktop 
publishing and word processing in a 
single software package. FrameMak¬ 
er seems well-suited for writing 
company newsletters, memos, and 
letters (it comes with templates for 
these), but its strong suit is large 
documents like user manuals, tech¬ 
nical reports, and proposals. 

I looked at the Windows version, 
which sells for $795. The recom¬ 
mended configuration is a 386 with 8 
Mbytes of RAM, at least 20 Mbytes 
of disk space, and a VGA monitor 
with a 1,024 x 768 resolution. (The 
minimum configuration uses 4 
Mbytes of RAM, 10 Mbytes of disk 
space, and a 640 x 480 resolution. I 
used Comtrade’s 33-MHz 486,16 
Mbytes of RAM, and the recom¬ 
mended display. 

FrameMaker is available on a 
wide range of operating systems, in¬ 
cluding Unix and Macintosh, so you 
can easily interchange documents 
among them. If your company has a 
system mix, FrameMaker can ease 
your desktop publishing and word 
processing needs. For example, peo¬ 
ple working together on the same 
proposal or user manual could use 
PCs and Sun workstations, sharing 
files through networking or elec¬ 
tronic mail. 

The basic layout tools are what 


you expect from a desktop publish¬ 
ing system. As its name implies, the 
product is frame-based. You place 
frames (resizable rectangles) on the 
page and add text, graphics, tables, 
and so on to the frames. Fortunate¬ 
ly, FrameMaker comes with enough 
predefined document templates so 
that you usually need to add frames 
only for items not part of the normal 
flow, like figures and breakout boxes. 

The package is very easy to use. 
Figure 2 is a typical screen image 
created as part of the tutorial. No¬ 
tice the four pop-up menus on the 
right of the image. These come up 
in response to the four tool icons 
that appear in the right-hand bor¬ 
der. These movable menus provide a 
quick way to use the tools you need. In 
particular, the long narrow menu con¬ 
tains the drawing tools. 

The small and large Z icons on the 
bottom right of the screen are zoom 
tools that use 10 preset zoom sizes 
(you can redefine them from 25 to 
1,600 percent). The small z reduces 
the image to the next smallest size, 
while the large Z increases it. 

You can import graphics and text 
into a FrameMaker document. It 
supports a wide range of graphics 
formats. You can import Microsoft 
Word and Excel files as well as Dis- 
playWriter, but WordPerfect is 
among the many document formats 
not directly supported. I imported a 
Word 2.0 document and found that 
most of the document appeared 



... stdoc] 


The Disappearing Rain 11> Natural Source ot Productsu 

Forests!] At least a quarter of all pha* 

by Michael Ratener, Ph.DJj 


Figure 2. FrameMaker screen. 


properly. Only small caps and a 
drop shadow effect didn’t appear 
correctly. 

As a word processor, FrameMak¬ 
er has most of what you need. In 
particular, it supports easy mathe¬ 
matical text entry and table cre¬ 
ation. It has a good spelling checker, 
but Word users will be disappointed 
in the lack of a thesaurus and gram¬ 
mar checker. These would be very 
useful additions. 

FrameMaker needs to add some 
special effects like drop shadowing. 
You can achieve this effect manually 
by superimposing a white rectangle 
over a black one and grouping them 
to ensure they can be moved or re¬ 
sized as a unit. However, automatic 
drop shadowing is so common in 
desktop publishing packages that 
FrameMaker should provide it. 

In addition to superior automatic 
hyphenation and pagination, Frame- 
Maker’s conditional text feature 
makes it easy to maintain multiple 
versions of a document. I used it to 
create proposal boilerplate that lets 
me emphasize any combination of 
my consulting expertise. I also used 
the conditional text feature to tailor 
Microsoft and X Windows versions 
of a user manual I’m writing. 

The package provides automatic 
generation of tables of contents, fig¬ 
ures, and tables. It also simplifies 
bibliography and index preparation. 
Large documents can be divided 
into separate files, say, on a chapter 
basis with the file names placed in a 
special book file. This allows you to 
work on a chapter at a time but still 
have access to the information with¬ 
in the entire document. 

Finally, you can use FrameMak- 
er’s impressive capabilities to build 
on-line hypertext-based documents. 
Both text and graphics can be used 
as active areas for moving through 
the document. 

Two additional tools, FrameView- 
er and FrameReader, are not quite 
ready for Windows. These tools let 
you distribute your FrameMaker 
documents. I hope to tell you about 
them at a later time. 

Although I have used Donald 
Knuth’s Tex typesetting system for 
almost all my document-preparation 
needs, I’m so impressed with Frame- 
Maker that I’m switching over. 

Readers can contact Frame Tech¬ 
nology at 1010 Rincon Circle, San 
Jose, CA 95131; (408) 433-3311; or 
circle Reader Service Number 27. 

— T.L. (Frank) Pappas, Aweb 
Software Technology 
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11th Symposium on 
Reliable Distributed Systems 

October 5-7,1992 

Wyndham Warwick Hotel, Houston, Texas 


THEME 


SPONSORS 

IEEE Computer Society TC on Distributed Processing 
IEEE Computer Society TC on Fault-Tolerant Computing 
IFIPWG 10.4 on Dependable Computing 
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The theme of this symposium is reliability of distributed and parallel systems, including distributed applications, distributed operating systems, and 
distributed databases. It includes 27 technical papers covering topics such as replicated servers and data management, checkpointing, reliable 
protocols, robust decentralized algorithms, design and evaluation of reliable distributed systems, self-stabilization, and language support for 
distributed systems. 

Keynote speaker: Jim Gray, Digital Equipment Corporation 


October 5 

October 6 

October 7 

1st Tutorial (full day) 

“Efficiency Management of 
Replicated Data” 

by J.-F. Paris (University of Houston) 

8:00-9:00 Registration 

8:30 -10:00 4th/Tools Sessions 

9:05-9:15 Welcome Address 


9:15-10:00 Keynote Speech 

10:00-10:30 Break 

10:00-10:30 Break 

10:30-12:00 1st Session 

10:30 -12:00 5th/Tools Sessions 

2nd Tutorial (full day) 

“Reliability and Performance Evaluation of 
Distributed Database Systems: 

A Practical Approach” 

by A. Helal (University of Texas at Arlington) & 
B. Bhargava (Purdue University) 

12:00-13:30 Lunch 

12:00-13:30 Lunch 

13:30 - 15:00 2nd Session 

13:30-15:00 6th/7th Sessions 

15:00-15:30 Break 

15:00-15:30 Break 

15:30 -17:00 3rd Session 

15:30-17:00 8th/9th Sessions 

17:00- 18:00 Panel 


Reception 

Buffet 


• Session 1: Replicated Data Management 

• Session 2: Experimental Performance Evaluation 

• Session 3: Distributed Control (Algorithms) 

• Session 4: Reliability and Performance Analysis 

• Session 5: Communication Protocols 

• Session 6: Checkpointing and Logging (Algorithms) 


• Session 7: Error Management 

• Session 8: Dependable System Design 

• Session 9: Programming Languages Support 

• Panel Session: “Future Research Directions in Distributed Comput¬ 
ing Systems”. Panelists from AFOSR, NSWC, ONR, Rome Lab. 

• Tools Session: Demonstration of state-of-the-art software tools for 
analyzing the performance and reliability of distributed systems. 


HOTEL RESERVATION 

Rates: Single - $87.00; Double - $97.00. Wyndham Warwick Hotel, 5701 Main Street, Houston, Texas, 77005; U.S.A. 

The cutoff date for reservations at these special rates is TUESDAY, SEPTEMBER 15. Please call or fax your reservation requests directly to 
the hotel and mention IEEE COMPUTER SOCIETY SPECIAL RATES FOR SRDS. Phone: USA (800-822-4200); Texas (713-526-1991); 
Canada (800-631-4200); Europe/UK (011-44-081-367-5175). Fax: USA and Canada (713-639-4545); Europe/UK (011-44-081-367-9949). 


CONFERENCE/TUTORIAL REGISTRATION 

Early registration for either the conference or the tutorial must be 
received by September 10,1992. Payment must be remitted by 
check or money order in U.S. currency only, payable to SRDS-11. 

Enter Tutorial (1 or 2) you wish to register for: Tutorial_ 

Total Enclosed: $_ 


Please circle appplicable charges: 


*Student registrations are not available for authors. 


Please return registration form and fee to: 

Farokh B. Bastani 
Attn: SRDS-11 

University of Houston, Department of Computer Science 
Houston, TX 77204-3475 USA 

For more information, contact Farokh B. Bastani: 

Phone: 713-743-3354; Fax: 713-743-3335; 

E-mail: coscfb@cs.uh.edu 


z Name 


a. Company 



City/State/Zip/Country 


a! IEEE/CS Membership Number (required for member rate) 











































NEW PRODUCTS _ 

Contact or send releases to Christine Miller, Computer , 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1264; Internet, s.c. miller @ compmail.com. 


RISC-based portable workstations 


NoteBook’s Model T50 


Toshiba has announced three 
RISC-based portables for its LT series 
of Sparc-compatible workstations, 
currently available only in Japan. 

The AS1000/G30, weighing 8.4 kg, 
is designed for engineering applica¬ 
tions. Its processing speed is 23 MIPS. 
It offers 16 Mbytes of main memory, 
expandable up to 48 Mbytes. The 
electroluminescent display (1,152 x 


The Dell 320SLi, based on the Intel 
386SL microprocessor running at 20 
MHz, weighs 3.6 pounds with battery 
and measures 7.75 x 11 x 1.25 inches. 
Features that reduce weight include 
non-edgelit LCD technology and a 
Lightpack portable diskette drive that 
connects to the system through a par¬ 
allel port. The Lightpack drive mea- 


Texas Instruments has introduced 
the 4000 series of its TravelMate note¬ 
book computers. The 4000 series com¬ 
prises three models based on the Intel 
486 processor with 4 Mbytes of main 
memory standard. All three models 
include enhanced 640 x 480 VGA dis¬ 
play that support 64 gray scales. All 
three allow an external 640 x 480 col¬ 
or monitor to display simultaneously. 

The TM4000 WinSX/16 has expand¬ 
able main memory to 8 Mbytes and 
comes with 512 Kbytes of video mem¬ 
ory and an 80-Mbyte hard disk drive. 

The main memories of the 25-MHz 
models, WinSX/25 and WinDX/25, 
are expandable to 20 Mbytes. These 
models include 1 Mbyte of video 
memory and 120 Mbyte-hard disk 
drives. They can also directly support 
1,024 x 768 resolutions on external 
monitors. 

All three models come with Win¬ 
dows 3.1 and MS-DOS 5.0 prein- 


900 pixels) provides a 16-level gray¬ 
scale screen. Priced at ¥1,880,000. 

The AS1000/E25 and AS1000/L25 
operate at 17.5 MIPS with 8 Mbytes of 
main memory, and come in either 
electroluminescent (E25) or active- 
matrix LCD (L25) displays. Available 
in Japan for ¥1,280,000 and ¥1,380,000. 
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sures 4.2 x 5.8 x 0.7 inches and weighs 
12 ounces. Other features include up 
to 10 Mbytes of system memory and 
120 Mbytes of storage, a PCMCIA 2.0 
slot, and Dell’s integrated keyboard 
mouse support. 

Prices range from $2,149 to $2,649. 
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stalled on the hard drive and TI’s 
TravelPoint pointing device. 

Weights range from 5.6 to 6 pounds; 
prices, from $3,199 to $4,199. 

Reader Service Number 37 



TravelMate 4000 WinDX/25 is TI’s 
highest performing notebook PC at 25 
MHz with 4 Mbytes of main memory. 


NoteBook Computer Company’s 
Model T50 486NoteBook is based on 
Intel’s i486DX2 microprocessor. The 
standard system configuration in¬ 
cludes 4 Mbytes of RAM, of which 2.5 
Mbytes are 25-ns, 32-bit CMOS 
SRAM, an 80- or 120-Mbyte 2.5-inch 
hard disk, and a black-on-white triple¬ 
supertwist VGA LCD that measures 
10 inches diagonally. The 486Note- 
Book weighs 5 pounds with an inter¬ 
nal battery and measures 8.5 x 11 x 
1.4 inches. Prices start at $4,899. 
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Notepad 386 chic 

Lighthorse Technologies’ Notepad 
is a 386SX 20-MHz portable computer 
designed in a sleek leather portfolio. 
The open-faced computer is 1.5 inches 
thick with a hinged, VGA-compatible 
LCD display. It comes with MS-DOS 
5.0, 2 Mbytes of RAM (expandable to 
4 Mbytes), a 3.5-inch floppy drive, and 
a 40-, 60-, or 80-Mbyte hard drive. A 
9600-baud send and receive fax, 2400- 
baud modem, and PS/2 mouse port 
are also standard. 

Price with 40-Mbyte drive is $2,995. 
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Lighthorse Technologies packages its 
Notepad 386SX inside a leather port¬ 
folio carrying case. 


Dell 320SLi weighs under 4 pounds 


TravelMate 4000 WinSXl6/25 and WinDX/25 — 
486 laptops optimized for Windows 
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Write once, read across 
user interfaces 

Uniface has announced its Univer¬ 
sal Presentation Interface (UPI), a 
development tool that transparently 
supports character and graphic mode 
presentation. UPI lets developers 
write client/server applications that 
will display data on desktop comput¬ 
ers running MS-Windows 3.1, Motif, 
and Open Look graphical user inter¬ 
faces. It also runs GUI applications 
under character mode. 

A specific driver supports each 
GUI, providing applications with all 
the features of that environment. The 
company plans to release drivers for 
other GUIs, including Presentation 
Manager/Workplace Shell later this 
year. 

UPI is part of the new release of 
Uniface 5.2, the company’s applica¬ 
tion development environment. Pric¬ 
ing of Uniface ranges from $5,000 to 
$250,000, while prices of the GUI 
drivers range from $350 to $32,000, 
based on hardware platform and con¬ 
figuration. 

Reader Service Number 40 


3D imaging software 
for Wavetracer 
supercomputers 

Wavetracer’s Image Processing Li¬ 
brary of 2D and 3D parallel imaging 
algorithms runs on the company’s 
Data Transport Computer product 
family. These parallel computers em¬ 
ploy up to 16,384 microprocessors act¬ 
ing simultaneously, offering the per¬ 
formance required for large 2D and 
3D image processing problems. 

The Data Transport Computers 
work with Unix-based workstations 
from Hewlett-Packard, IBM, Silicon 
Graphics, Sun Microsystems, and Ap¬ 
ple. These workstation users can ac¬ 
cess the Image Processing Library 
transparently through their window¬ 
ing environments and thereby address 
complex 2D and 3D applications in 
such areas as medical imaging, satel¬ 
lite data processing, seismic interpre¬ 
tation, and movie production. 

Wavetracer’s Image Processing Li¬ 
brary is priced at $10,000. Its comput¬ 
ers are priced from $85,000 to 
$350,000. 
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The UnMouse for 
OEMs 

MicroTouch System’s retail Un- 
Mouse touch tablet is now available to 
OEMs, customized to their specifica¬ 
tions. In particular, this touch-sensi¬ 
tive tablet — typically 2x3 inches — 
gives notebooks a built-in pointing de¬ 
vice for Windows and OS/2 applica¬ 
tions. The glass sensor is 1.5-mm thick 
and relies on capacitive sensing to ini¬ 
tiate cursor movement. It provides 
pixel-by-pixel cursor control from 
1,000 x 1,000 touch-sensitive points. 
Pricing, which includes the sensor, 
CMOS chip set, and software, begins 
at $40 in quantities of 1,000. 
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The Microtouch OEM UnMouse can 
be customized to fit manufacturers’ 
specifications. To move the cursor, 
users touch the tablet’s glass surface. 


Ncube introduces 2S supercomputers 


Ncube has announced its 2S family 
of massively parallel supercomputers. 
According to the company, the 2S line 
features an improved version of 
Ncube’s custom microprocessor and 
up to 64 Mbytes of memory per pro¬ 
cessor. A fully configured system, 
with 8,192 processors and 512 Gbytes 
of main memory, delivers 34-Gflops 


and 123,000-MIPS performance. Like 
all Ncube systems, the 2S features 
Ncube’s Parallel Software Environ¬ 
ment for development, based on the 
industry-standard System V Release 4 
version of Unix. 

List prices begin at $360,000. 
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Macintosh software for digitized waveforms 


MacScience Solutions has released 
WaveTrak, software for the acquisi¬ 
tion and management of digitized 
waveforms. WaveTrak is designed for 
scientists and engineers who need to 
acquire large numbers of digital wave¬ 
forms and store them for future refer¬ 
ence. WaveTrak solves the problem of 
locating acquired data by storing each 
separate digitized trace on a separate 
card of a HyperCard stack. In addi¬ 
tion to the data, the card can store a 
time stamp, hardware parameters, and 



WaveTrak provides a library of buttons 


annotations to support search and re¬ 
trieval. 

WaveTrak requires a Macintosh II 
series CPU with a math coprocessor 
and the GW Instruments MacAdiosII 
NuBus card. Display and Traces can 
be exported in Text, Piet, or Igor for¬ 
mats. 

Price for a single copy is $695; for 
two to five copies, $595; and for five 
or more, $495. 



to customize application routines. 


August 1992 


89 































































PC-to-mainframe 

connectivity 


AutoCAD drawing-to- Ada source code 
DFX translator management 


Linkup 3270 UniSession for Win¬ 
dows, a product from Computer Log¬ 
ics, offers windowed or full-screen 
3270 terminal emulation from a PC 
under Windows 3.1. It links through a 
coax connection to an IBM 3174 or 
compatible controller and appears to 
the controller as an IBM InfoWindow 
3472 display terminal. 

A Windows-based installation and 
setup program installs the emulation 
and file transfer software, customizes 
the software for the user’s system, and 
adds LinkUp icons to the desktop. It 
supports file transfer and direct print¬ 
ing from the host to the user’s PC- 
attached printer. 

LinkUp 3270 UniSession for Win¬ 
dows, including software and the 
LinkUp Coax Adapter, lists for $765. 
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Perfect DXF, a 1:1 translator of Au¬ 
toCAD drawings to industry-standard 
DXF file format, has been released by 
SoftSource. According to the compa¬ 
ny, the translator eliminates Auto¬ 
CAD’s proprietary file barrier, pro¬ 
viding a fast bridge between Auto¬ 
CAD drawings and other programs. 

Perfect DXF is available to soft¬ 
ware developers who want to give 
their applications access to Auto¬ 
CAD. For applications with access to 
DXF file format, developers can pro¬ 
vide Perfect DXF as an optional utili¬ 
ty. It can also be purchased as private- 
label bundling. 

Perfect DXF runs under MS/PC 
DOS, Sun OS, DEC Ultrix, and MS 
Windows. Pricing starts at $50/unit in 
quantities of 100. 
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Erratum: New Products introduced a speech-recognition system called Phonetic 
Engine 400 in the June issue and mistakenly identified its manufacturer as Sound 
Systems Inc. The manufacturer for Phonetic Engine 400 is Speech Systems Inc. 


Software Maintenance & Develop¬ 
ment Systems has released ADC/ 
AdaScan, the newest of its language 
scanners for Aide-De-Camp, the com¬ 
pany’s object-oriented software con¬ 
figuration management system. 

ADC/AdaScan helps developers 
identify and track the relations be¬ 
tween components of Ada programs. 
It finds which source files belong to a 
specific program, tells what major 
program structures the files contain 
and the order in which to compile 
them for building executable code. It 
also identifies the types of Ada 
program units a compilation order 
represents, such as a specification, 
body, package, procedure, task, or ge¬ 
neric. 

Pricing for ADC/AdaScan is set at 
$2,195 for all supported platforms, 
which include IBM RS/6000, DEC, 
Sun Sparc, Hewlett-Packard, Silicon 
Graphics, Mips, and 386/486-based 
Unix systems. 
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FIRST INTERNATIONAL CONFERENCE ON 
~ INTELLIGENT AND COOPERATIVE 
4> INFORMATION SYSTEM (ICICIS) ' ' A 

May 12 - 14, 1993, Erasmus University, Rotterdam, The Netherlands 
Sponsored by Erasmus Univ. & Queensland Univ. of Technology, Bribane, Australia 
In cooperation with IEEE Computer Society, AAAI, and The Dutch Computer Society 

CALL FOR PAPERS 

The ICICIS conference will provide a forum for both AI and DB research communities to share ideas for identifying 
potential roles and nature of emerging notions of ICIS, leading to ICIS inter-disciplinary research and development. 
Program Committee: Mike Papazoglou (Gen. Chair), Mike Huhns & Guenther Schlageter (Co-Program Chairs), 
Bruce Blum, Patrick Bobbie, Nick Bourbakis, Mike Brodie, Ed Durfee, Les Gasser, Jaap van den Herik, John Hughes, 
Matt Jarkes, Yahiko Kambayashi, D. Karagiannis, Stefan Kim, Bemd Kraemer, Fred Lochovsky, Louis Marinos, Bob 
Meersman, J. Mylopoulos, J. Schreinemakers, T. Sellis, S. Urban, Joe Urban, John Vittal, Ben Wah, and N. Yoshida. 
Suggested Topics for ICIS: Novel Architectures, Modeling & Reasoning Techniques, Knowledge Engineering, High 
Level Descriptive Langs., Data/Knowledge Representation, Managing & Coord Multiple Coop Agents, Interoperability 
Issues, Partitioning & Integration, Active Decision Support, Coop User Interfacing, Transaction Scheduling. 
Instructions for Submission: Authors should submit 4 copies in a double-spaced format, not to exceed 5000 words to 
(Europe/Africa) - G. Schlageter, Fem Univ. Hagen, Praktische Info I, Feithstrasse 140, D-5800, Hagen, Germany; 
(Americas) - M. Huhns, MCC, 3500 W. Balcones Ctr Dr., Austin, TX 78759, USA, huhns@mcc.com; (Australiasia) 

- M. Papazoglou, QUT, Fac of Info Tech, GPO Box 2434, Brisbane QLD 4001, Australia, mikep@snow.fit.qut.edu.au 
IMPORTANT DATA: Papers due October 19, 1992; Acceptance notification: Jan. 10th, 1993; Camera ready copies 
due February 20, 1993. Proceedings will be published by IEEE-CS Press & selected papers will appear in IJICIS. 







GUIDES 

Authors are strongly encouraged to 
obtain the complete Call for Participation 
and the INTERCHI '93 Guides for 
Successful Submissions. These include 
information for all submission categories 
and can be obtained by: 

« E-mail to:ic93-submission- 
guides@bellcore.com 
ASCII text and RTF formats will 
automatically be sent to the message's 
return address. 

■ Anonymous FTP from 
flash.bellcore.com 

to obtain: 

/pub/ic93-submission-guides.txt 
(ASCII text), or 

/pub/ic93-submission-guides.rtf 

(RTF) 

• E-mail or written request to any 
Technical Programme Committee 
member. 

■ Written request to either conference 
office. 

SUBMISSION DEADLINES: 
31 July 1992 

■ Tutorials 

■ Workshops 
31 August 1992 

■ Doctoral Consortium 
(application requests) 

18 September 1992 

■ Papers 

■ Panels 

■ Overviews 

■ Demonstrations 

■ Videos 

15 January 1993 

■ Short Papers 

■ Special Interest Groups (SIGs) 

■ Interactive Experience 

NORTH AMERICAN OFFICE 

Carol Klyver 

INTERCHI '93 North-American Office 

P.O. Box 1279 

1355 Redwood Way 

Pacifica, CA 94044 USA 

Tel: +1 415 7381200 

Fax: +1 415 738 1280 

E-maii: ic93-office-na.chi@xerox.com 

EUROPEAN OFFICE 

Elly Lammers or Charlotte White 

INTERCHI '93 European Office 

University of Twente 

P.O. Box 217 

7500 AE Enschede 

The Netherlands 

Tel: + 31 74 50 40 44 

Fax: + 31 74 50 40 44 

E-mail: ic93-office.chi@xerox.com 

Express Mail Address: 

INTERCHI '93 Office 
Dolf Nijhoffstraat 7 
7552 GP Hengelo 
The Netherlands 



BRIDGES BETWEEN WORLDS 

1993 Conference on Human Factors in Computing Systems 

CHI ’93 and INTERACT ’93 ^ 

24 - 29 April 1993, Amsterdam, The Netherlands 

INTERCHI '93 is a continuation and blending of the traditions of 
ACM/SIGCHI's annual CHI conference and IFIP TC 13’s tri-annual 
INTERACT conference. It combines the two leading events for 
researchers, developers, and users in the field of Human-Computer 
Interaction (HCI). This conference is a bridge between many kinds of 
worlds: countries and continents; languages and cultures; scientific 
disciplines; theory and application; academia, industry, and users; 
researchers, developers, educators, consultants, lawyers, and civil 
servants; varying skills and capabilities; diverse applications, services, 
and functions. 

INTERCHI '93 bridges a traditional view of HCI and a new one. This 
new view is multifaceted: computing is present everywhere not only 
via workstations; communication is low cost and instantaneous; new 
input and output devices extend beyond keyboards and displays; 
applications encompass the casual and the critical, work and play, and 
art and science; isolated perspectives are integrated; the user is 
recognized as part of a social, physical and technical environment; the 
process of design is as important as the resulting products; 
and design is responsive to regulation, standardisation, and legal 
protection. 

With this view in mind, we invite you to participate in INTERCHI ’93 by 
submitting original work from all areas of HCI in the participation formats 
described, and by meeting with us in Amsterdam to experience and discuss 
the world of HCI. 


Call for Participation 















1C A nnouncements _ 

Company, Model, Function_Comments r.S. No. 


Analog Devices Amplifier features 5-ppm/°C maximum gain drift and 0.6-pV/°C voltage offset drift — the in- 121 

AD621 dustry’s lowest, according to the company. Packaged in an 8-pin SOIC or DIP with pin-strap- 

instrumentation amp pable gains of 10 and 100 and a 1.3 mA maximum supply current. Operates from power sup¬ 

plies between ±2.3V to ±18V. 


AS AT Advanced Semiconductor Assembly Technology has announced a plastic body package fam- 122 

TQFP ily, the Thin Quad Flat Pack, with a body thickness of 1.4 mm and overall package height of 

IC packaging 1.6 mm maximum. Several package sizes and lead count combinations are available, ranging 

from 7x7 mm and 32-leads to 14 x 14 mm and 100 leads. 


Burr-Brown 
OPA678 
Op amp 


Calex 

K Triple series 
DC/DC converters 


Cognex 

VC-2 

Custom vision chip 

Fujitsu Micro¬ 
electronics 
E128VH 
ASIC 

Hitachi 

HN58V1001/257 

EEPROMs 


Mitsubishi 

MGF-7121/-7051 

MMICs 


Music Semiconductors 

MU9C4870/ 

4870V/4870A 


Color palettes 


Power General 
HD1-15 series 
DC/DC converters 


Texas Instruments 
SN74ACT8994 
Digital bus monitor 


VLSI Technology 
ARM610 

RISC microprocessor 


Wideband monolithic operational amplifier has two independent differential inputs either of 123 
which can be selected by an external TTL or ECL signal. Input selection speed is 4 ns. Key 
specifications include 200-MHz bandwidth, 11-ns settling time (1%), ±380 (TV offset voltage, 
and 350V/ps slew rate. Offered in a 0.6-inch plastic DIP and SOIC. Price (in 100s): $5.95. 

Calex’s 55 W triple-output converters, designed with two separate power sections, are now 124 

available with an optional heat sink that eliminates the need to add forced air cooling devices 
to a system. Cased in 0.04-inch-thick aluminum that measures 3.5x5.5x0.9 inches. Price (in 
100s): $150.50. 

On-chip image processing operations (neighborhood and frame) are optimized for machine 125 

vision applications on Cognex 3000 and 4000 Series systems. Measures 375-mm square in a 
standard cell array implemented in 1 -micron CMOS. Packaged in 84-pin PLCC. 

Application-specific integrated circuit device implements ECL circuit design, 0.3-pm Si- 126 

bipolar processing, and 10-GHz packaging technologies to achieve data rates up to 6 Gbits/s. 
Features 128 gates and gate speeds of 40 ps at 1mA of emitter current. Packaged in a round 
ceramic 28-pin flat pack. Price (in 10,000s): $140. 

Nonvolatile memory devices operate from 3 V supplies. Both devices feature byte- and page- 127 

erase/programming modes. 20-mW/MHz dissipation when active, 100-pW (maximum) dissi¬ 
pation in standby, and V cc range of 2.7 to 5.5V. HN58V1001 is a 128K x 8-bit device with 250- 
ns access time; HN58V257 is 32K x 8 bits and 350 ns. Available in 32-pin TSOPs. Price (in 
100s): $45 (HN58V1001); $18 (HN58V257). 

Two GaAs microwave monolithic ICs can be used in wireless modems, LANs, and miniatur- 128 

ized cellular phones. MGF7121 is a three-stage amp IC for use in output transmitter circuitry. 
MGF7051 is a single-pole, double-throw switch for use as a diplexer. 

Monolithic ICs display 256 colors or, in Direct Color Mode, up to 64K colors using any VGA 129 

controller’s 256-color mode. DCM also supports high color mode of Tseng Labs’ ET4000 
graphics controller. MU9C4870 sets DAC current with external current reference, while V 
and A versions use on-chip or external voltage reference. All devices allow read and write ac¬ 
cess to the lookup table when the display is active. Price (in 100s): from $6.95 to $8.45. 

Single-output, 15 W converters come in 2 x 2 x 0.4-inch modular format with outputs of 5 V at 130 

3 A, 12V at 1.25 A, or 15 V at 1A and inputs of 9-18 V, 18-36V, or 36-72V. Devices have interna¬ 
tional safety agency approvals, including UL1950, CSA22.2-234/950, and VDE0805/ 
EN60950/IEC950. MTBF is 300,000 hours minimum; power density is 9.4W/in. Price (in 
quantities from 250 to 499): $51.25. 

Testability device emulates the functions of logic and signature analysis test instruments. 131 
Gives a nonintrusive method for monitoring the real-time functional operation of digital cir¬ 
cuits to designers using the JTAG/IEEE 1149.1-1990 test standard. Fabricated in one-micron 
advanced CMOS and packaged in 28-pin PLCC. Price (in 1,000s): $20. 

This 32-bit device offers 29K Dhrystones at 25 MHz with a dissipation of less than 600 mW. 132 

Includes a memory management unit, 4 Kbytes of cache memory, write buffer, and full 
boundary scan circuitry. Fully supported by software development systems that run on Sun, 

DOS, and Macintosh operating systems. Packaged in a 144-pin TQFT. Prototypes are avail¬ 
able. Price (in 1,000s): $46.49. 
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BENEFITS 


Receive Computer automat¬ 
ically with membership. Writ¬ 
ten and refereed by experts, 
it features articles on the latest 
developments in computer 
technology, applications, and 
research, as well as survey 
and tutorial articles on topics 
covering the entire computer 
field. 

Computer's popular depart¬ 
ments include New Products, 
Product Reviews, Book 
Reviews, Standards, Open 
Channel (a reader forum), and 
Computer Society News. 

Other membership benefits include the following: 

• Discounts of up to 50% on Computer Society Press 
books and videos. Over 700 titles covering a broad 
spectrum of computer science topics including net¬ 
working, communications, advanced systems, image 
processing, security, artificial intelligence, and 
visualization 

• Discounts on registration to over 100 conferences, 
workshops, and tutorials each year 

• Low subscription rates on special-interest periodicals 

• Opportunity to participate in any of our 32 technical 
committees—networks of professionals with common 
interests in computer hardware, software, and 



• Opportunity to participate in the development of more 
than 200 standards projects sponsored by the society 

• Low member rates on COMPMAIL, the electronic mail 
service especially designed for computer 


Schedule of Fees 


To join: see item 1, 2, or 3. 
To subscribe: see item 4. 


Membership dues and periodical subscriptions are annualized to, and expire oi 
December 31. Pay full- or half-year rate depending on date of receipt by the 


A 1 don’t belong to the IEEE and 1 want 

1 to join just the Computer Society 



□ $27 

□ $ 54 

o 1 want to join both the Computer Society 






£ and the IEEE* 






1 reside in Region 1-6 (United States). 


□ 

$58.50 

□ $117 

1 reside in Region 7 (Canada). 


□ 

$53.50 

□ $107 

1 reside in Region 8 (Europe, Africa, or the Middle East) 

□ 

$53.00 

□ $106 

1 reside in Region 9 (Latin America). 


□ 

$49.50 

□ $ 

99 

1 reside in Region 10 (Asia and Pacific). 


□ 

$48.50 

□ $ 

97 

’ACM members who join both IEEE and the Computer Society may deduct $5 off the 


full-year rate; $2.50 off the half-year rate. 






O 1 already belong to the IEEE and 1 want 
O to join the Computer Society 


□ 

$11.00 

□ $22 






IEEE Member Number 






^ SPECIAL-INTEREST PERIODICALS for 

new or 

current members 


IEEE Computer Graphics and Applications... 

..' SS . UeS 6 Pe ' 

□ 

$12.50 

□ $ 

25 

IEEE Design and Test . 

.4 

□ 

$11.00 

□ $ 

22 

IEEE Expert . 

.6 

□ 

$10.00 

□ $ 

20 

IEEE Micro . 

.6 

□ 

$11.50 

□ $ 

23 

IEEE Software . 

.6 

□ 

$12.50 

□ $ 

25 

Transactions on: 






Computers . 

.12 

□ 

$12.00 

□ $ 

24 

Knowledge and Data Engineering . 

.6 

□ 

$ 9.50 

□ $ 

19 

Parallel and Distributed Systems . 

.6 

□ 

$ 9.50 

□ $ 

19 

Pattern Analysis and Machine Intelligence. 

.12 

□ 

$12.00 

□ $ 

24 

Software Engineering . 

.12 

□ 

$11.00 

□ $ 

22 

IEEE Annals of the History of Computing . 

.4 

□ 

$ 8.00 

□ $ 

16 


□ Visa □ MasterCard □ American Express 
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Charge Card Number (Minimum Charge $10) 

Checks drawn in local currency on a bank in the coun- 


Periodicals total $_ 

CA, DC residents add 
applicable sales tax $_ 

Membership fees $_ 

Total $_ 


CANADIAN residents 
add 7% GST; BELGIAN 
residents add 6% VAT $_ 


MAILING ADDRESS 


EDUCATION (highest level completed) _ 


ENDORSER (an IEEE me 


OCCUPATION 


IEEE Member No. 


Mail or fax to appropriate Computer Society office: 

EUROPE: 13, Avenue de I’Aquilon, B-1200, Brussels, BELGIUM. Fax: 32-2-770-8505 

PACIFIC RIM: Ooshima Building, 2-19-1 Minami-Aoyama, Minato-ku, Tokyo 107, JAPAN. Fax: 81-3-3408-3553 

ALL OTHERS: 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1264 USA. Fax: 714-821-4010 
























































Microsystem Announcements 


Barco Chromatics 
CX3500 

Graphics controller 


Computer Modules 
Flash Disk 
PC memory board 


Data Technology 
DTC2290 

IDE-EIS A host adapter 


DSP Design 
GCAT 

PC on credit card 


Hytec Electronics 
VDS2081 
VMEbus display 


JDR Microdevices 
IDE hard/floppy 
drive controller 


Loral Defense Systems 
ASPRO-VME 
Parallel computer 


MNC International 
MNC1150 
Solid-state disk 


ProTege 
PalmDrive 
Hard disk drive 


Smart Modular 
Technologies 
SmartRAM 
Memory card family 

Spectrum 

DT-Connect/DPS-Link 
Interface board 


Zyktronix 
Little Monster II 
Single-board computer 


Multihead, multiresolution, single-board controller drives one display at 2,560x 2,048 or 
2,048 x 2,048 and a second at the same or lower resolution. Also supports correct cursor posi¬ 
tioning between monitors for a cost-effective solution in applications, such as air-traffic con¬ 
trol, that might otherwise require two systems. Price: from $27,850. 

Based on Intel’s Flash technology, PC AT-bus compatible nonvolatile memory board emu¬ 
lates a hard disk. It can be erased and programmed in the PC. DOS drivers enable use of stan¬ 
dard disk operating instructions. Offers fast access, EPROM capability, and expandability. 
Single in-line memory modules plug into board, providing 1-16 Mbytes of memory in 1- 
Mbyte increments. Price: 16-socket board, $1,095; 4-socket, $795; 1-Mbyte SIMM, $250. 

Allows integrated-drive-electronics disk drives to perform at their maximum data rates on 
the EISA bus. Supports up to four 8-Gbyte IDE drives for a maximum of 32 Gbytes per card. 
Also supports up to four floppy devices, including the newer 2.88-Mbyte drives. Fully com¬ 
patible with all IDE disk drives and most PC operating environments. Price: $145. 

Credit card-sized PC compatible uses Chips & Technologies’ 14-MHz F8680 processor. 
Built-in graphics hardware drives a CG A LCD screen or CRT. COM1 hardware-compatible 
serial port can be reconfigured as RS485. PCMCIA memory card interface accepts up to 256 
Kbytes of SRAM and 256 Kbytes of Flash EEPROM. Price: $799. 

Plug-in module monitors VMEbus lines and displays, or captures and reads out data using 
on-board registers, to aid in system assembly and fault finding. Single-width module, with 
both connectors fitted, operates as a D32/A16, A24, or A32 device and includes 32 front- 
panel switches to generate data patterns or specify addresses. 

Controls four integrated-drive-electronics hard drives — even on MS-DOS systems, since 
they appear as two logical drives, overcoming DOS’s two-drive limit. Features on-board 
basic I/O and cache; uses single in-line memory modules, with one SIMM required. Avail¬ 
able with I/O and video and in 8-bit version. Price: 16-bit basic version, $19.95. 

Modular, associative/parallel processing computer is programmable in Ada. Basicconfigu- 
ration consists of three 6U VME modules and can perform 150 million floating-point opera¬ 
tions and two billion integer-arithmetic operations per second. With expansion to 18 VME 
modules, performance increases to two and 80 billion operations, respectively. 

MS-DOS compatible, solid-state system with PCMCIA 2.0 slot for ISA and EISA computers 
uses semiconductor memory instead of mechanical disks. Supports memory cards up to 64 
Mbytes with 16-bit data path; provides eight 32-pin JEDEC sockets for SRAM, EPROM, 
EEPROM, and Flash RAM chips. Price: Evaluation units, $295. 

Designed for data and application transportability, this external disk-drive system fits in the 
palm of your hand and interfaces to desktop and notebook PCs via ProTege’s Stealth con¬ 
trollers. With up to 5 Mbyte/second data transfer from drive buffer to host, the unit can sup¬ 
port Windows applications. Price: 40-Mbyte unit, $599; 120-Mbyte, $999. 

Nonvolatile memory cards for pen-based and palm-top systems combine Flash and SRAM 
technologies to improve write cycle times and power consumption. About the size of a thick 
credit card, the devices include a built-in controller and battery backup circuitry. Average 
read-access and write-cycle times are 150 ns each. Price (in 100s): 1-Mbyte card, $160. 

PC plug-in board bridges Data Translation’s DT-Connect interface with Spectrum Signal 
Processing’s DSP-Link. DT-Connect provides direct connection of standalone data acquisi¬ 
tion, frame grabber boards, and processing boards. DSP-Link is a bidirectional, 16-bit paral¬ 
lel bus that provides a high-bandwidth data path between DSP devices and peripheral expan¬ 
sion boards. Price: $795. 

New version of “the world’s smallest” 386sx AT-compatible, single-board computer for 
embedded and ruggedized applications measures 4x6 inches. It now includes 2 Mbytes of 
on-board DRAM, expandable to 16 Mbytes, and a PLCC ROM socket for user system soft¬ 
ware. Price: 20-MHz version (250-piece quantity), $889; development kit, $1,595. 
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CALL FOR PAPERS 
30TH ACM/IEEE 

DESIGN AUTOMATION CONFERENCE * 

DALLAS CONVENTION CENTER • JUNE 14 -18,1993 



D AC is the premier conference devoted solely to the field of Design 
Automation. All aspects of the use of computers as aids to the 
design process are included, from conceptual design through 
manufacturing. Four types of sessions are included: regular paper 
sessions, short paper sessions, panels, and tutorials. 


REQUIREMENTS FOR SUBMISSION OF PAPERS 


Authors should submit their papers to the Program Chair postmarked 
no later than October 23, 1992. Each submission should include 
one cover page and eight stapled copies of the complete manuscript. 
The one cover page should include: 

• Name, affiliation, and complete address for each author 

• A designated contact person including his/her telephone 
number, fax number, and e-mail address 

• A designated presenter, should the paper be accepted 

• A list of topic numbers, ordered by relevancy, most 
clearly matching the content of the paper. It is critical that 
the topic number(s) accurately reflect the content of the 
paper. If your paper spans more than one topic, please 
indicate this. 

• The following signed statement: “All appropriate organi¬ 
zational approvals for the publication of this paper have 
been obtained. If accepted, the author(s) will prepare the 
final manuscript in time for inclusion in the Conference 
proceedings and will present the paper at the Conference.” 

The eight copies of the complete manuscript should include the 
following items. To permit a blind review, do not include 
name(s) or affiliation(s) of the author(s) on the manuscript. 

•Title of paper 

•60-word abstract indicating significance of contribution 

•The complete text of the paper in English, including all 
illustrations and references, not exceeding 5000 words. 
Overly long papers will not be considered. The papers will 
be reviewed as finished papers. Preliminary submissions 
will be at a disadvantage. 

Notice of acceptance will be mailed to the contact person by 
February 20, 1993. Authors of accepted papers must sign a 
copyright release form. 


PANELS, TUTORIALS, 
SPECIAL TOPIC SESSIONS 


Proposals for topics of Panels, Tutorial Sessions, and Full-day 
Tutorials should be submitted to the Program Chair no later than 
October 23, 1992. Each proposal should not exceed two pages in 
length and should include a description of the topic, structure of the 
session or tutorial, and a list of participants. You should make 
contact with all participants in advance. 

Special Topic Sessions may be either independent papers with a 
common theme or a set of closely related papers describing an 
overall system. In both cases, independent reviews of each paper 
and evaluation of the session as a whole will be used to select 
sessions. Proposals for Special Topic Sessions should be submitted 
along with the papers to be included in the session and should 
describe the theme of the session. These proposals and paper 
submissions must be postmarked no later then October 23, 1992. 


TOPICS OF INTEREST 


Authors are invited to submit original technical papers describing 
recent and novel research or engineering developments in all areas 
of design automation. Topics include, but are not limited to: 

1.1 Electrical Simulation 

1.2 Discrete Simulation 

1.3 Timing Verification 

2.1 Testing, Fault Simulation, Test Pattern Generation, Test 
Validation and Design-for-Testability 

2.2 Formal Hardware Verification 

3.1 Floorplanning and Placement 

3.2 Global and Detailed Routing 

3.3 Physical Module Generation 

3.4 Symbolic Layout and Compaction 

3.5 Complete Layout Systems 

3.6 Layout Verification (DRC, ERC) 

4.1 Technology-independent, Combinational Logic Synthesis and 
Optimization 

4.2 Technology Mapping and the Interaction Between Logic 
Synthesis and Layout 

4.3 Sequential Synthesis and Optimization 

4.4 High-level Synthesis and System-level Design Aids 

4.5 Asynchronous Synthesis 

5.1 Hardware Description Languages 

5.2 Design Systems and Databases 

6.1 DA for IC Fabrication 

6.2 Computer Aids for Manufacturing 

7.1 DA for Analog Circuits 

7.2 High-speed Systems and Microwave DA 

7.3 DA for Electronic Packaging 

7.4 Technology CAD 

8.1 Human Factors in DA 

8.2 Frameworks in DA 

8.3 Software Engineering in DA 

8.4 Hardware/Software Codesign 

9.1 Complete DA Systems 

9.2 User Experience with DA Systems 

9.3 Electronic Design Using DA, Design Methodology 



The Design Automation Conference has expanded its emphasis in 
the use of DA tools. We are soliciting papers and proposals for panels 
and tutorials of interest to system and circuit designers, design 
mangers and DA support engineers. Use topic numbers 9.1,9.2 and 9.3 
for submissions in these areas. 

• Use of automation in the design of state-of-the-art systems 

• Design methodology and design process to take advantage of 
DA systems 

• Standards issues: VHDL/CFI/ED1F 

• Personal computer DA 

• Partnering with EDA vendors 

• Silicon strategies: FPGA, PLD, and ASIC 

• Comparative results of using multiple DA systems 

• Complete DA systems; tools built on top of frameworks; 
integrating vendor tools within your system 


PROGRAM CHAIR 


MP Associates, Inc. 

ATTN: Bryan Preas 

Program Chair, 30th DAC 

7490 Clubhouse Rd„ Suite 102 

Boulder, Colorado 80301 

For information call: (303) 530-4333 


sponsored by: 
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EDITOR-IN-CHIEF 


Dr. Sung-Mo (Steve) Kang 
University of Illinois 
Coordinated Science Lab 
307 N Mathews 
Urbana, IL 61801 
Tel: (217)-244-0577 
Fax: (217)-244-1653 
kang@uivlsi.csl.uiuc.edu 


ASSOCIATE EDITORS 

Prof. Jacob A. Abraham 
Univ of Texas at Austin 

Prof. Prithviraj Banerjee 
Univ of Illinois at Urbana 

Prof. Donald W. Bouldin 
Univ of Tennessee 

Prof. Robert W. Brodersen 
Univ of California 

Prof. John Hennessy 
Stanford University 

Dr. Dwight Hill 
AT&T Bell Labs 

Dr. William Joyner 
IBM TJ Watson Res Ctr 

Dr. Nick Kanopoulos 
Research Triangle Inst 

Prof. Carver Mead 
California Inst of Tech 

Prof. Bing J. Sheu 

Univ of Southern California 

Prof. Donald E. Thomas 
Carnegie Mellon Univ 

Dr. C. K. Wong 
IBM TJ Watson Res Ctr 

Dr. Ping Yang 
Texas Instruments 


Starting in January 1993, the IEEE Transactions on VLSI Systems will 
be published as a new quarterly journal under the cosponsorship of IEEE 
Circuits and Systems Society, IEEE Computer Society, and IEEE Solid-State 
Circuits Council. Design and realization of microelectronic systems using 
VLSI/ULSI technologies require close collaboration among scientists and 
engineers in the fields of systems architecture, logic and circuit design, chips 
and wafers fabrication, packaging, testing and systems applications. Genera¬ 
tion of specifications, design and verification must be performed at all 
abstraction levels, including the systems, register-transfer, logic, circuit, 
transistor and process levels. To address this critical area through a common 
forum, the IEEE Transactions on VLSI Systems has been founded. The edi¬ 
torial board, consisting of international experts, invites original papers which 
emphasize and merit the novel systems integration aspects of microelectronic 
systems, including interactions among systems design and partitioning, logic 
and memory design, digital and analog circuit design, layout synthesis, CAD 
tools, chips and wafer fabrication, testing and packaging, and systems level 
qualification. Thus, the coverage of this new Transactions will focus on 
VLSI/ULSI systems integration. Topics of special interest include, but are 
not strictly limited to, the following: 

• Systems Specifications, Design and Partitioning 

• System-Level Test 

• Reliable VLSI/ULSI Systems 

• High Performance Computing and Communication Systems 

• Wafer Scale Integration and Multichip Modules (MCMs) 

• High-Speed Interconnects in Microelectronic Systems 

• VLSI/ULSI Neural Networks and Their Applications 

• Mixed Analog/Digital Systems 

• Cost, Performance Tradeoffs of VLSI/ULSI Systems 

Prospective authors are requested to submit seven copies of the com¬ 
plete manuscript of up to 25 double-spaced typewritten pages, plus up to 10 
pages of figures. Shorter papers of 6 or less pages and up to 3 pages of 
figures will be considered for publication as a Transactions Brief Paper. 
Manuscripts should be sent to the Editor-in-Chief. 

Members of the sponsoring IEEE Societies may subscribe to this new 
Transactions for $12 per year which will be published quarterly in 1993. 
Contact IEEE Service Center, 445 Hoes Lane, Piscataway, NJ 08855-1331, 
Phone: 908-981-0060. 
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‘Factory’ concept challenges software management 


Ware Myers, Contributing Editor 

Why are there so many problems in 
developing software? Why do these 
problems continue to appear year af¬ 
ter year, decade after decade? What 
kind of solutions have firms tried to 
offer? Michael A. Cusumano, associ¬ 
ate professor of the Sloan School of 
Management at the Massachusetts In¬ 
stitute of Technology, posed those 
questions when he delivered the key¬ 
note address June 9 at the 29th IEEE/ 
ACM Design Automation Conference 
in Anaheim, California. 

Cusumano began his study of the 
software problem in 1985. He investi¬ 
gated large firms in the United States 
and — aided by his fluency in Japa¬ 
nese — Japan. His results were re¬ 
ported at length in his 513-page book 
Japan’s Software Factories: A Chal¬ 
lenge to US Management (Oxford 
University Press, 1991). 

When his book came out, some peo¬ 
ple expected an imminent announce¬ 
ment that the next industry the Japa¬ 
nese were going to take over was 
software. “I am not naive enough to 
make that sort of claim,” Cusumano 
said with a smile. “I do claim that the 
Japanese have struggled with software 
development for a long time — 20 to 
25 years. They have struggled with the 
problem of how to make complex sys¬ 
tem development into a more routine 
activity.” 

Cusumano found that the large Jap¬ 
anese firms are very good in software 
development. On the one hand, “the 
firms that I have studied — Hitachi, 
Toshiba, Fujitsu, and NEC — may be 
as good as any software development 
organization in the world, at least 
their most advanced facilities,” he as¬ 
serted. “There is a lot that we can 
learn from them about how to manage 
this technology more effectively.” On 
the other hand, “the average software 
development company in Japan is a 
fairly loosely organized job shop. 
Much like in the United States, they 
do not have a formal process.” 

Based on a survey of 40 large-scale 
systems in Japan and the US, Cu¬ 
sumano concluded that the Japanese 
are developing large systems with 
“maybe” 40 to 50 percent higher lev¬ 
els of productivity than Americans. 

He measured productivity “rather 


crudely,” he admitted, “in lines of 
source code per person-month, adjust¬ 
ed by the language. But the Japanese 
numbers were extremely good. Per¬ 
haps more important, the Japanese 
had one-third to one-half the number 
of nondeferrable faults in the first 12 
months after delivery.” 

Software development is difficult. 

Others have listed as many as 30 or 40 
problem areas, but Cusumano 
grouped them into four categories. 

One is that building large systems, 
particularly for the first time, is inher¬ 
ently complex. 

Second, developers not only have to 
understand the tools and techniques 
of software engineering, but they also 
have to understand a particular appli¬ 
cation domain. Thus, if developers are 
frequently shifting domains or moving 
from company to company, as hap¬ 
pens in the US, they find it hard to 
accumulate experience and reuse it. 

Third, developers not only need 
knowledge of software engineering 
and domains, they also are up against 
a potentially enormous variety of user 
requirements. “If the requirements 
are indeed infinite, then a factory-like 
approach is impossible,” Cusumano 
pointed out. “If there is a lot of com¬ 
monality, then we can talk about be¬ 
ing more systematic.” 

Fourth, “once we think we have 
mastered how to build particular 
kinds of systems, the hardware plat¬ 
form will change, languages will 
change,” he continued. “A lot of the 
progress we think we have made is 
suddenly not very helpful.” 

These are indeed serious problems. 
He said one approach to solving them 
(to oversimplify outrageously) has 
been to hire the best people available, 
lock them in a room, and hope for the 
best. Unfortunately, the result has of¬ 
ten turned out to be expensive, late, 
and defective, he said. 

Cusumano argues, rather, that the 
industry has actually accumulated 
quite a lot of knowledge about all 
these problem areas in the past 20 or 
30 years. “The problem now is that 
this knowledge — in the form of good 
practices — is not systematically ap¬ 
plied,” he said. “I think this is because 


managers — and engineers, in particu¬ 
lar — tend to view each project as 
unique and as reliant on unique indi¬ 
vidual knowledge.” 

On the one hand, projects being 
done for the first time — that is, 
projects in what Cusumano calls “the 
invention mode” — are different in 
various degrees from more repetitive 
projects. “On the other hand, if each 
project is managed as if it were a 
unique enterprise, then there is no 
way for the organization to accumu¬ 
late process knowledge in the sense of 
common methods, common tools, re¬ 
usable designs,” he said. “An addi¬ 
tional problem is that software organi¬ 
zations have not effectively found 
ways to balance individuality, the 
need for creativity among individuals, 
or the need to be efficient.” 

The Japanese software factory. For 

historic and cultural reasons, the Jap¬ 
anese tended to go down the path to 
efficiency to a somewhat greater ex¬ 
tent than the Americans did. For in¬ 
stance, they had a severe shortage of 
skilled software people. They couldn’t 
just hire the best ones and lock them 
in a room. 

Also, during this period, about 70 to 
80 percent of the demand in Japan 
was for custom software. “But all the 
functionality requirements were not 
really unique,” Cusumano noted. 
“There was a lot of redundancy or po¬ 
tential reusability across the designs.” 
The Japanese saw that they needed a 
way to capture it. 

All together, the Japanese approach 
came to be known as “the software 
factory.” The Japanese word trans¬ 
lates to either “factory” or “works.” 
Cusumano feels that “works” proba¬ 
bly comes closer to expressing what 
the Japanese meant. At any rate, to- 
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day many Japanese do not like the 
connotations of “factory.” The Hita¬ 
chi Software Works, for example, is 
now called the Hitachi Development 
Center. It is housed in twin non¬ 
factory-like 31-story office towers. 

The 4,000 people in the towers think 
of themselves as professionals. 

In some sense, however, the Japa¬ 
nese software works are “factories” if 
by factories we mean systematic orga¬ 
nizations that develop standards, 
tools, methods, etc., that enable peo¬ 
ple to function in a predictable, con¬ 
trollable fashion. These standard tools 
and methods are not easily introduced 
into a project-based organization. “In 
a project system, the project manager 
has the final word,” Cusumano said. 
“He determines the methods and 
tools used and the time to ship.” 

In Japan, however, the project 
structure is weak. “The powerful peo¬ 
ple in these organizations are the 
managers of the product-domain de¬ 
partments, systems engineering, and 
quality assurance,” he noted. “Man¬ 
agement of software development is 
above the project level, so that sup¬ 
port can go across projects and devel¬ 
op a common infrastructure that is not 
unique to each project.” 

At Hitachi, for instance, the quality 
assurance department, not the project, 
has the final word as to when a prod¬ 
uct is ready to ship. This department’s 
authority is extensive. It is responsible 
for the process from requirements on¬ 
ward. “Phase milestones are passed 
only when the quality people are satis¬ 
fied that the system is being devel¬ 
oped with the defined process,” Cu¬ 
sumano said. The quality department 
is in charge of testing and interfacing 
to customers. 

With a defined process, of course, it 
is possible to estimate work more ac¬ 
curately. “Hitachi has a database go¬ 
ing back to 1966 containing detailed 
data on every project it ever built,” 
Cusumano said. “[Hitachi] has made 
enormous improvements in project 
control, getting it down to around 15 
percent of projects going into final in¬ 
spection late. Actually, it doesn’t 
press this metric much. It doesn’t 
want to be schedule-driven; it wants 
to be quality-driven. It feels a reason¬ 
able number for late projects is some¬ 
where between 10 and 15 percent.” 

Since 1978, Hitachi has reduced its 
index of defects from 100 to six. “That 
translates into the neighborhood of 
0.07 faults per 1,000 lines of code the 
first 12 months after delivery,” Cu¬ 
sumano added. 

In 1991, Hitachi achieved about 
4,500 lines of equivalent assembler 


source code per developer per month, 
according to Cusumano. “That trans¬ 
lates to about 1,500 lines of C-type 
code, or about 500 lines of new code 
per developer person,” he said. “Still, 
new-code productivity has not gone up 
nearly as much as reuse productivity.” 

“Measuring reuse is a thorny prob¬ 
lem,” he admitted, “but Toshiba, for 
instance, improved from a 15 percent 
reuse rate a few years ago to 49 per¬ 
cent in 1985 and 65 percent in 1991.” 

People argue about the best way to 
measure productivity or quality. They 
debate how best to manage software 
development. “Because there is no 
one best way that we know of, many 
organizations are paralyzed,” Cu¬ 
sumano claimed. “They just do not de¬ 
velop standards, and the organization 
does not proceed.” 

The large Japanese companies, how¬ 
ever, have not waited for the best 
ways. They keep changing their ways 
— incrementally. “It is a way of allow¬ 
ing the organization to capture exper¬ 
tise and improve,” he concluded. 


Keynoter recognizes 
India’s potential 



IEEE Trans, on VLSI Systems will 
begin quarterly publication in Janu¬ 
ary 1993, under the cosponsorship of the 
IEEE’s Computer Soc., Circuits and Sys¬ 
tems Soc., and Solid-State Circuits Coun¬ 
cil. Coverage will focus on VLSI/ULSI sys¬ 
tems integration. Submit seven copies of 
the complete manuscript (up to 25 double¬ 
spaced pages and up to three pages of fig¬ 
ures) to Sung-Mo (Steve) Kang, Editor-in- 
Chief, Coordinated Science Lab, Univ. of 
Illinois, 1101 W. Springfield Ave., Urbana, 
IL 61801-3082, phone (217) 244-0577, fax 
(217) 244-1653, e-mail kang@uivlsi.csl.uiuc. 


hit'l J. on Very Large Data Bases is be¬ 
ginning quarterly publication. For further 
information and for manuscript guidelines, 
contact Fred J. Maryanski, Univ. of Con¬ 
necticut, U-86, 352 Mansfield Rd., Storrs, 
CT 06269-2086, phone (203) 486-2421, fax 
(203) 486-6379, e-mail fred@provost.vpa. 
uconn.edu (for the Americas and Asia); or 
Hans-J. Schek, Swiss Federal Inst, of 
Tech., Zurich, ETH Zentrum, CH-8092 
Zurich, Switzerland, phone 41 (1) 254- 
7240, fax 41 (1) 262-3973, e-mail schek@ 
inf.ethz.ch (for Europe, Africa, and Oce- 


Sharad Seth, University of Nebraska 

Richard Newton of the University of 
California at Berkeley recognized In¬ 
dia’s vast potential in software and de¬ 
sign expertise when he presented the 
keynote address at the Fifth Interna¬ 
tional Conference on VLSI Design. 

Regarding India’s potential, Newton 
referenced the examples of Cadence 
and Texas Instruments. He said that 
conferences like this, held in Banga¬ 
lore, India, January 4-7, provide direc¬ 
tion to CAD developers and research¬ 
ers and help them meet industry needs. 

Many attendees cited Bernard Cour- 
tois’ efforts in spreading VLSI design 
expertise throughout Europe as anoth¬ 
er example to follow. Courtois deliv¬ 
ered a plenary talk on the French Mul¬ 
tichip Project. 

Asoke K. Laha of Cadence Design 
Systems and Lalit M. Patnaik of the In¬ 
dian Institute of Science served as the 
general cochairs of VLSI Design 92. 
The VLSI Society of India sponsored 
the conference. Cooperating organiza¬ 
tions included the IEEE Computer So¬ 
ciety’s Technical Committees on De¬ 
sign Automation and VLSI. 

VLSI Design 93 will be held January 
3-6,1993, in Bombay, India. Informa¬ 
tion can be obtained by contacting the 
publicity chair, R. Rajsuman by 
e-mail at rajsuman@alpha.ces.cwru.edu. 


Int’l Conf. on Signals, Data, and Systems— 
Methodologies and Applications: Dec. 7-9, 
1992, Calcutta, India. Sponsor: Int’l Assoc, 
for the Advancement of Modeling and 
Simulation Technology in Enterprises et 
al. Submit two copies of one-page summa¬ 
ry by Aug. 20, 1992, to AMSE, 16 Av. 
Grange Blanche, 69160 Tassin-la-Demi- 
Lune, France, fax (33) 78-34-54-17. 

J. of Computer and Software Eng. seeks 
papers on various topics and applications 
for its issues No. 1 and 2 of 1994. Publish¬ 
er: Ablex. Submit five copies of full manu¬ 
script by Aug. 21,1992, to E.K. Park, Com¬ 
puter Science Dept., US Naval Academy, 
Annapolis, MD 21402, phone (410) 267- 
3037, fax (410) 267-4883, e-mail eun@usna. 
navy.mil. 

OE/Technology 92, Optical Tools for Ad¬ 
vanced Manufacturing and Optical Tech¬ 
nologies and Applications: Nov. 25-20, 

1992, Boston. Sponsor: Int’l Soc. for Opti¬ 
cal Eng. Submit abstract by Aug. 24,1992, 
and manuscript by Oct. 19,1992 to SPIE, 
PO Box 10, Bellingham, WA 98227-0010, 
phone (206) 676-3290, fax (206) 647-1445. 

CAIA 93, Ninth IEEE Conf. on Arti¬ 
ficial Intelligence for Applications: 

Mar. 1-5,1993, Orlando, Fla. Submit four 
copies of short paper (up to 1,000 words) 
with extended abstract or long paper (up 
to 5,000 words) with 200-word abstract by 
Aug. 31,1992, and final paper by Dec. 14, 
1992, to David Waltz, Thinking Machines 
Corp., 245 1st St., Cambridge, MA 02142- 
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1214, phone (617) 234-2050, fax (617) 234- 
4444, e-mail waltz@think.com. 

Solid Modeling 93, Second ACM/ 
IEEE Symp. on Solid Modeling and 
Applications: May 19-21,1993, Montreal, 
Canada. Submit abstract (150-300 words) 
by Sept. 1,1992. full paper (6,000-word 
maximum) by Oct. 15,1992, and camera- 
ready version by Feb. 7,1993, to Mary 


Johnson, Design Research Center, CII 
7015, Rensselaer Polytechnic Inst., Troy, 
NY 12180-3590, phone (518) 276-6751, fax 
(518) 276-2702, e-mail mjohnson@rdrc.rpi. 
edu. 

Int’l J. of Computer Simulation seeks 
manuscripts for a special issue on simula¬ 
tion metamodeling of production systems. 
Publisher: Ablex. Submit five copies of full 


paper by Sept. 1,1992, to Christian N. 
Madu, Management Science Dept., Lubin 
Graduate School of Business, Pace Univ., 1 
Pace Plaza, New York, NY 10038, phone 
(212) 346-1919 or 1980, fax (212) 346-1872. 

SIGCSE 93,24th Technical Symp. on 
Computer Science Education: Feb. 18-19, 
1993, Indianapolis, Ind. Sponsor: ACM. 
For paper submittal requirements, contact 
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Call for articles and referees for Computer 


Computer seeks articles for inclusion in future special issues. 


Heterogeneous processing will be the theme of the June 1993 issue. See p. 100 of the July 1992 issue of Computer for 
complete information about the nature of the submittals being solicited. 

Fourteen copies of each full manuscript must be submitted by September 6, 1992; notification of decisions is set for Janu¬ 
ary 4,1993; and the final version of each manuscript is due March 1, 1993. 

Direct submittals and questions to Richard F. Freund, NRaD, Code 423, 271 Catalina Blvd., San Diego, CA 92152-5000, 
phone (619) 553-4071, fax (619) 553-3926, e-mail freund@superc.nosc.mil. Questions may also be directed to H.J. Siegel, 
School of Electrical Engineering, 1285 Electrical Engineering Bldg., Purdue University, West Lafayette, IN 47907-1285, phone 
(317) 494-3444, fax (317) 494-6440, e-mail hj@ecn.purdue.edu. 


Extending the functionality of a telecommunications system will be the theme of the August 1993 issue. Manuscripts 
surveying or reporting original research, design and development, and applications are sought immediately in 


• Classification of the kinds of problems raised by extending the functionality of telecommunications systems 

• Modeling, reasoning, and testing techniques for detecting feature interactions between different software components of 
a telecommunications system 

• Techniques for dynamic resolution of conflicts arising because of interactions between users or software components of 
a telecommunication system 

• Software platforms and architectures for preventing or resolving interactions between different software components of a 
telecommunications system 

• Tools and methodologies for promoting software compatibility and extensibility 

• Environment and automated tools for related problems in other software systems 

• Solution techniques used for actual telecommunication systems 

A 300-word abstract of each manuscript must be submitted by September 15, 1992; 14 copies of each full manuscript must 
be submitted by November 15, 1992; notification of decisions is set for March 1,1993; and the final version of each manu¬ 
script is due April 15,1993. 

Direct submittals and questions to Nancy D. Griffeth, Bellcore MRE 2L-237, 445 South St., Morristown, NJ 07962-1910, 
phone (201) 829-4538, e-mail nancyg@bellcore.com; or Yow-Jian Lin, Bellcore MRE 2Q-277, 445 South St., Morristown, NJ 
07962-1910, phone (201) 829-4635, e-mail yowjian@bellcore.com. 


Visualization will be the theme of the July 1994 issue. See p. 100 of the July 1992 issue of Computer tor complete infor¬ 
mation about the nature of the submittals being solicited. 

A 300-word abstract of each manuscript is due by June 15,1993; 14 copies of each full manuscript must be submitted by 
August 1,1993; notification of decisions is set for January 15,1994; and the final version of each manuscript is due March 
1, 1994. 

Submittals and questions should be directed to Arie E. Kaufman, Dept, of Computer Science, State University of New York 
at Stony Brook, Stony Brook, NY 11794-4400, phone (516) 632-8441, e-mail ari@cs.sunysb.edu. 


For submittal to Computer, manuscripts must not have been previously published or currently submitted for publication 
elsewhere. Each manuscript should be no more than 32 typewritten, double-spaced, single-sided pages long, including 
all text, figures, and references. Each of the 14 copies submitted should include a page that contains the title of the arti¬ 
cle, the full name(s) and affiliation(s) of the author(s), complete postal and electronic address(es) of all the authors as 
well as their telephone and fax number(s), a 300-word abstract, and a list of keywords identifying the central issues of the 
manuscript’s contents. The final manuscript should be approximately 8,000 words in length and contain no more than 12 
references. 

If you are willing to review articles for any special issue, please send a note listing your research interests to Jon T. 
Butler, editor-in-chief of Computer, at the Dept, of Electrical and Computer Engineering, Naval Postgraduate School, 
Code EC/Bu, Monterey, CA 93943-5004, Internet butler@ece.nps.navy.mil. 
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Call for articles and referees for IEEE Computer Society magazines 


The following IEEE magazines seek articles for inclusion in future issues: 


> EEE Design & Test of Computers seeks general-interest articles (20 double-spaced pages, including figures) for its 1993 
issues. Suggested topics include reviews of tools, design experiences, and design methodologies; use of CAE/CAD tools in 
the design process; test strategies and economics; DFT vs. cost; D/A test; system-level trade-offs; rapid prototyping; packag¬ 
ing; manufacturing databases; and special-purpose tools. Submit a 300-word abstract, keywords, and your mail/e-mail ad¬ 
dresses, along with six copies of the article, to Manuel d’Abreu, GE R&D, 1 River Rd„ PO Box 8, KW-C308, Schenectady NY 
12301, phone (518) 387-7097, fax (518) 387-7332, dabreu@crd.ge.com. 


> EEE Software seeks articles for inclusion in a special issue on software synthesis to appear in May 1993. Reusability using 
software synthesis techniques, domain-specific software synthesis, and handling of cost trade-offs in software synthesis are 
examples of the topics of interest. Eight copies of previously unpublished articles should be sent by Sept. 1, 1992, and final 
versions are due by Jan. 15, 1993. Make submittals to Dorothy Setliff, 341 Benedum Hall, Electrical Eng. Dept., Univ of Pitts¬ 
burgh, Pittsburgh, PA 15261, phone (412) 624-9695, fax (412) 624-1108, e-mail setliff@ee.pitt.edu. 


Cary Laxer or Frank Young, Rose-Hulman 
Inst, of Tech., Terre Haute, IN 47803, 
phone (812) 877-8401, e-mail laxer@cs. 
rose-hulman.edu. Submittal deadline: Sept. 

1,1992. 


EDAC 93, Fourth European Design 
Automation Conf. and EuroASIC 
93, European Event in ASIC Design: Feb. 
22-25,1993, Paris. Submit paper by Sept. 2, 
1992, and final version of manuscript by 
Nov. 27,1992, to EDAC-EuroASIC 93, 
CEP Consultants, 26-28 Albany St., Edin¬ 
burgh, EH1 3QH, Scotland, phone 44 (31) 
557-2478, fax 44 (31) 557-5749. 


Int’I Multiconference on Application of 
Signals, Data, and Systems Methodologies 
to Eng. Problems: Dec. 28-30,1992, Alex¬ 
andria, Egypt. Sponsor: Int’l Assoc, for the 
Advancement of Modeling and Simulation 
Technology in Enterprises et al. Submit 
two copies of one-page summary by Sept. 

10,1992, to AMSE, 16 Av. Grange 
Blanche, 69160 Tassin-la-Demi-Lune, 
France, fax (33) 78-34-54-17. 


yfj ) ETC 93, European Test Conf.: Apr. 

19-24,1993, Rotterdam, The Nether¬ 
lands. Submit four copies of paper by Sept. 

11,1992, and camera-ready manuscript by 
Jan. 22,1993, to Jacques Kevers, ETC 93 
Secretariat, IEEE Computer Soc., 13 Ave¬ 
nue de l’Aquilon, B-1200 Brussels, Bel¬ 
gium, phone 32 (2) 770-22-42 or 21-98, fax 
32 (2) 770-85-05, e-mail j.kevers@ 
compmail.com. 


kj Third Int'l Symp. on Database Sys- 
" terns for Advanced Applications: 


Apr. 6-8,1993, Deajon, Korea. Sponsors: 
Korean Information Science Soc., Informa¬ 
tion Processing Soc. of Japan. Submit six 
copies of full paper (5,000-word maximum) 
by Sept. 12,1992, to SongChun Moon, 207- 
43 Cheongryang, Dongdaemun, Seoul 130- 
012, Korea, fax 82 (2) 960-6743, e-mail 
moon@dbsun2.kaist.ac.kr. 


(jjj) 26th Simulation Symp.: Mar. 29-Apr. 
NS? 1,1993, Washington, D.C. Sponsor: 
Soc. for Computer Simulation. Submit four 
copies of complete paper (10 to 20 double¬ 


spaced pages) by Sept. 15,1992, to John A. 
Miller, Computer Science Dept., 415 Grad¬ 
uate Studies Research Center, Univ. of 
Georgia, Athens, GA 30602, phone (706) 
or (404) 542-3440, e-mail jam@pollux.cs. 
uga.edu. 


OTM IWSR 93, Second Int’l Workshop on 
N!?' Software Reusability: Mar. 24-26, 
1993, Lucca, Pisa, Italy. Cosponsors: ACM 
SIGSoft et al. Submit five copies of full pa¬ 
per by Sept. 15,1992, and camera-ready 
version by Dec. 15,1992, to Bill Frakes, 
Software Eng. Guild, 400 Drew Ct., Ster¬ 
ling, VA 22170, phone (703) 450-5954, 
e-mail 70761.1176@CompuServe.com. 

(jcjjfo CompEuro 93: May 24-27,1993, Par- 
vS?' is-Evry, France. Submit paper by 
Sept. 15,1992, and final manuscript by 
Feb. 15,1993, to CompEuro 93, do Societe 
des Electriciens et des Electroniciens, 48 
rue de la Procession, F-75724 Paris, Cedex 
15, France, phone 33 (1) 44-49-60-60, fax 
33 (1) 44-49-60-44. 


J. of Systems and Software plans a special 
issue on fault tolerance in real-time sys¬ 
tems. Publisher: Elsevier. Submit five cop¬ 
ies of full manuscript by Sept. 15,1992, to 
Hoang Pham, Idaho Nat’l Eng. Lab., PO 
Box 1625, MS 2406, Idaho Falls, ID 83415, 
phone (208) 526-9274, fax (208) 526-2930, 
e-mail hgp@inel.gov. 


Fourth Int’l Hong Kong Computer Soc. 
Database Workshop: Dec. 12-13,1992, 
Hong Kong. Submit four copies of paper 
(6,000-word limit) by Sept. 15,1992, to 
Vincent Lum, Systems Eng. Dept., Chinese 
Univ. of Hong Kong, Shatin, Hong Kong. 

CHI 93,1993 Conf. on Human Factors in 
Computing Systems, and Interchi 93/Inter¬ 
act 93: Apr. 24-29,1993, Amsterdam. 
Sponsor: ACM. Submit paper by Sept. 18, 
1992, to Carol Klyver, Interchi, PO Box 
1279,1355 Redwood Way, Pacifica, CA 
94044, phone (415) 738-1200, fax (415) 
738-1280, e-mail ic93-office-na.chi@xerox. 
com (for North Am.); or Elly Lammers or 
Charlotte White, Univ. of Twente, PO Box 
217, 7500 AE Enschede, The Netherlands, 


phone (31) 74-50-40-44, e-mail ic93- 
office.chi@xerox.com (for Europe). 

Second IEEE Int’l Conf. on Fuzzy Sys¬ 
tems: Mar. 28-Apr. 1,1993, San Francisco. 
Sponsor: IEEE Neural Network Council. 
Submit six copies of paper (eight-page 
maximum) and abstract by Sept. 21,1992, 
to Piero P. Bonissone, General Electric 
CR&D, Bldg. K-l, Rm. 5C32A, 1 River 
Rd., Schenectady, NY 12301. 


ICNN 93,1993 IEEE Int’l Conf. on Neural 
Networks: Mar. 28-Apr. 1,1993, San Fran¬ 
cisco. Sponsor: IEEE Neural Network 
Council. Submit six copies of paper (eight- 
page maximum) and abstract by Sept. 21, 
1992, to Hamid Berenji, Al Research 
Branch, MS 269-2, NASA Ames Research 
Center, Moffett Field, CA 94035. 


CTM IPPS 93, Seventh Int’l Parallel Pro- 

cessing Symp.: Apr. 13-16, 1993, 
Newport Beach, Calif. Cosponsor: ACM 
SIGArch. Submit five copies of complete 
manuscript (15 single-spaced pages maxi¬ 
mum) by Sept. 30,1992, and camera-ready 
paper by Jan. 29,1993, to Viktor K. 
Prasanna, EE Systems Dept., EEB 244, 
Univ. of Southern California, Los Angeles, 
CA 90089-2562, fax (213) 740-4449, e-mail 
ipps93@halcyon.usc.edu. 

CHDL 93, 20th Conf. on Hardware 

Description Languages and their Ap¬ 
plications: Apr. 26-28,1993, Ottawa, Cana¬ 
da. Sponsor: Int’l Federation for Informa¬ 
tion Processing. Submit six copies of paper 
by Oct. 5,1992, and camera-ready version 
by Feb. 1,1993, to Ottawa Carleton Re¬ 
search Inst., c/o Debby Sullivan, 340 March 
Rd., Suite 400, Kanata, Ont., Canada K2K 
2E4, phone (613) 592-8260, fax (613) 592- 
8163, e-mail trio@carleton.ca. 


® llth IEEE VLSI Test Symp.: Apr. 6- 
8,1993, Atlantic City, N.J. Cospon¬ 
sors: IEEE Computer Soc. Technical Com¬ 
mittee on Test Technology, IEEE Phila¬ 
delphia Section. Submit seven copies of 
proposal by Oct. 9,1992, and camera-ready 
copy by Jan. 29,1993, to Dhiraj Pradhan, 
Computer Science Dept., Texas A&M 
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Univ., College Station, TX 77843-3112, 
phone (409) 862-2438, fax (409) 862-2758, 
e-mail pradhan@ecs.umass. edu. 

ICDCS 93,13th Int’l Conf. on Dis- 

tributed Computing Systems: May 

25-28,1993, Pittsburgh. Submit six copies 
of double-spaced manuscript (20-page 
maximum) and abstract by Oct. 15,1992, 
to Larry Wittie, Z4400 Computer Science, 
SUNY at Stony Brook, Stony Brook, NY 
11794-4400, phone (516) 632-8456, fax 
(516) 632-8334, e-mail lw@sbcs.sunysb.edu. 

First IEEE Int’l Workshop on Sys- 

terns Management: Apr. 14-16,1993, 
Los Angeles. Submit 3- to 5-page position 
paper (extended abstract, summary, or 
working paper) by Oct. 16,1992, and six 
copies of the camera-ready manuscript by 
Jan. 22,1993, to Seraphin B. Calo, IBM 
Research Div., 30 Saw Mill River Rd., 
Hawthorne, NY 10532, phone (914) 784- 
7514, e-mail calo@watson. ibm.com. 

ICICIS 93, Int’l Conf. on Intelligent 
vftx and Cooperative Information Sys¬ 
tems: May 12-14,1993, Rotterdam, The 
Netherlands. Cosponsors: IEEE Computer 
Society et al. Submit five copies of full pa¬ 
per (5,000 words) by Oct. 19,1992, to 
Michael Huhns, MCC, 3500 W. Balcones 
Center Dr., Austin, TX 78759, e-mail 
huhns@mcc.com; Guenther Schlageter, 
Fern Univ., Hagen, Praktische Informatik 
I, Feithstrasse 140D-5800 Hagen, Germa¬ 
ny; or Mike Papazoglou, QUT School of 
Information Systems, Faculty of Informa¬ 
tion Tech., GPO Box 2434, Brisbane, QLD 
4001, Australia, e-mail mikep@snow.fit. 
qut.edu.au. 

1993 Int’l Symp. on Multiple-Valued 

Logic: May 24-27,1993, Sacramento, 
Calif. Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Multiple-Valued Log¬ 
ic. Submit five copies of 50- to 100-word 
abstract and paper by Nov. 1,1992, and 
camera-ready version by Mar. 1,1993, to 
Gerhard Dueck, Math and Computer Sci¬ 
ence Dept., St. Francis Xavier Univ., An- 
tigonish, N.S., B2G ICO, Canada, phone 
(902) 867-3972, fax (902) 867-5153, e-mail 
dueck@phoenix.stfx.ca (for submittals in 
the Americas); Daniel Etiemble, LRI, Bat 
490, Univ. Paris Sud, 91 405 Orsay Cedex, 
France, phone 33 (1) 69-41-66-21, fax 33 
(1) 69-41-65-86, e-mail de@lri.fr (for Eu¬ 
rope and Africa); or Michitaka Kameyama, 
Information Eng. Dept., Faculty of Eng., 
Tohoku Univ., Aoba Aramaki Aoba-ku, 
Sendai 980, Japan, phone 81 (22) 222-1800, 
ext. 4298, fax 81 (22) 263-9405, e-mail 
michi@kameyama.ecei.tohoku.ac.jp (for 
Asia and the Pacific). 

/£|)\ IEEE/ACM Int’l Conf. on Develop- 

ing and Managing Intelligent System 
Projects: Mar. 29-31,1993, Washington, 
D.C. Cosponsors: IEEE Computer Soc. 
Technical Committee on Expert Systems, 
ACM. Submit four copies of complete 
manuscript by Nov. 1,1992, to Mark Gem- 
bicki, TCS, 47 Randall St., Annapolis, MD 
21401. 
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In the accompanying Calendar and adjoining Call for Papers, the IEEE 
Computer Society logo identifies the conferences, symposiums, and work¬ 
shops the society is sponsoring or cooperating in. Other multiple-topic events of 
interest to our readers are also listed. The notices are published free of charge, in 
chronological order, and as space permits. 

For inclusion in the Call for Papers section, please submit the name of the 
event, date(s), location, sponsor(s), deadline for submittals, phone and fax num¬ 
bers, and — if applicable — the electronic address of the person to whom papers 
should be directed. 

For the Calendar section, please provide the event name, date(s), location, 
sponsor(s), phone and fax numbers, and the electronic address of the person to 
contact for complete information. 

Submittals should arrive at Computer at least five weeks before the month of 
publication (i.e., for the October 1992 issue, send information for receipt by 
August 20, 1992) to Chuck Governale, Calendar Dept., Computer, PO Box 3014, 
Los Alamitos, CA 90720-1264, fax (714) 821-4010, e-mail c.governale® 
compmail.com. 


August 1992 

Crypto 92, Aug. 16-20, Santa Bar- 
bara, Calif. Sponsor: Int’l Assoc, of 
Cryptologic Research. Contact Spyros S. 
Magliveras, Computer Science and Eng. 
Dept., Univ. of Nebraska, Lincoln, NE 
68588-0115, phone (402) 472-5005, fax 
(402) 472-7767, e-mail spyros@helios. 
unl.edu. 

SIGComm 92, Aug. 17-20, Baltimore. 
Sponsor: ACM. Contact J.J. Garcia-Luna, 
SRI Int’l, 333 Ravenswood Ave., Menlo 
Park, CA 94025, fax (415) 859-6028, e-mail 
sigcomm92-info@ihburn.att.com. 

ICPP 92,21st Int’l Conf. on Parallel Pro¬ 
cessing, Aug. 17-21, St. Charles, Ill. Spon¬ 
sor: Pennsylvania State Univ. Contact Tse- 
yun Feng, Penn State Univ., ECE Dept., 
EE East Bldg., University Park, PA 16802, 
phone (814) 863-1469, fax (814) 865-7065, 
e-mail tfeng@ecl.psu.edu. 

Computer-Based Design Environments 
Symp.-Workshop, Aug. 18-19, Baden- 
Baden, Germany. Contact Jens Pohl, CAD 
Research Unit, Cal Poly, San Luis Obispo, 
CA 93407, fax (805) 756-5986. 

/jjjN Int’l Workshop on Distributed Ob- 
ject Management, Aug. 19-21, Ed¬ 
monton, Alta., Canada. Cosponsors: Cana¬ 
dian Information Processing Soc. et al. 
Contact M. Tamer Ozsu, Computing Sci¬ 
ence Dept., Univ. of Alberta, Edmonton, 
Alta., Canada T6G 2H1, phone (403) 492- 
2860, fax (403) 492-1071. 

Int'l Conf. on Intelligent Systems Eng., 
Aug. 19-21, Edinburgh, UK. Sponsor: In¬ 
stitution of Electrical Engineers. Contact 
IEE Conf. Services,. Savoy Place, London 


WC2R 0BL, UK, phone (071) 240-1871, 
fax (071) 497-3633. 

VLDB 92, 18th Int’l Conf. on Very 
Large Data Bases, Aug. 23-27, Van¬ 
couver, B.C., Canada. Cosponsors: VLDB 
Endowment, Canadian Information Pro¬ 
cessing Soc. et al. Contact Paul Sorenson, 
Computer Science Dept., Univ. of Alberta, 
Edmonton, Alta., Canada T6G 2H1, phone 
(403) 492-4589, fax (403) 492-1071, e-mail 
vldb92@cs.ualberta.ca or sorenson@cs. 
ualberta.ca. 

Concur 92, Third Int’l Conf. on Concurren¬ 
cy Theory, Aug. 24-27, Stony Brook, N.Y. 
Sponsor: Nat’l Science Foundation. Con¬ 
tact Scott Smolka, Computer Science 
Dept., SUNY at Stony Brook, Stony 
Brook, NY 11794-4400, phone (516) 632- 
8453, fax (516) 632-8334, e-mail sas@sbcs. 
sunysb.edu. 

Simulation Conf. 17, Aug. 25-27, Arling¬ 
ton, Va. Cosponsors: Soc. for Computer 
Simulation et al. Contact CACI Products, 
3344 N. Torrey Pines Ct., La Jolla, CA 
92037, phone (619) 457-9681, fax (619) 
457-1184. 

UniForum Asia 1992 Conf., Aug. 25-28, 

Singapore. Sponsors: Information Comm. 
Inst, of Singapore et al. Contact UniForum 
Singapore, 190 Clemenceau Ave., #05-33/ 
34 Singapore Shopping Centre, Singapore 
0923, phone (65) 334-3512, fax (65) 334- 
0855. 

Int’l Workshop on Structural and Syntactic 
Pattern Recognition, Aug. 26-28, Bern, 
Switzerland. Sponsor: Int’l Assoc, for Pat¬ 
tern Recognition. Contact Horst Bunke, 
Inst, fur Informatik und angewandte Math- 
ematik, Univ. of Bern, Langgassstrasse 51, 
CH-3012 Bern, Switzerland, phone 41 (31) 










654451 or 658681, fax 41 (31) 653965, 
e-mail bunke@iam.unibe.ch. 

ICPR 92,11th lnt’1 Conf. on Pattern Rec¬ 
ognition, Aug. 30-Sept. 3, The Hague, The 
Netherlands. Sponsor: Int’l Assoc, for Pat¬ 
tern Recognition. Contact ICPR Secretari¬ 
at, Delft Univ. of Tech., Electrical Eng. 
Dept., PO Box 5031, NL-2600 GA Delft, 
The Netherlands, phone 31 (15) 786-052, 
fax 31 (15) 622-000, e-mail icpr@et.tudelft. 
nl. 

FPL 92, Second Int’l Workshop on Field- 
Programmable Logic and Applications, 
Aug. 31-Sept. 2, Vienna. Sponsors: Vienna 
Univ. of Tech., Univ. of Kaiserslautern. 
Contact Herbert Griinbacher, Vienna 
Univ. of Tech., Treitlstrasse 3, A-1040, Vi¬ 
enna, Austria, phone 43 (1) 58801-8150, 
fax 43 (1) 569697, e-mail herbert@vlsivie. 
tuwien.ac.at; or Reiner Hartenstein, Univ. 
of Kaiserslautern, PO Box 3049, D-W-6750 
Kaiserslautern, Germany, phone 49 (631) 
205-2606, fax 49 (631) 205-2640, e-mail 
hartenst@rhrk.uni-kl.de. 


September 1992 

Conpar 92, Int’l Conf. on Parallel Process¬ 
ing, and VAPP V, Vector and Parallel 
Processors in Computational Science, Sept. 
1-4, Lyon, France. Cosponsors: Int’l Feder¬ 
ation for Information Processing et al. 
Contact Michel Cosnard, Ecole Normale 
Superieure de Lyon, Laboratoire de 
l’lnformatique du Parallelisme 46, allee 
d’ltalie, 69364 Lyon Cedex 07, France, 
phone (33) 7272-8037, fax (33) 7272-8080, 
e-mail cosnard@frensl61.bitnet. 


POS 5, Fifth Int’l Workshop on Persistent 
Object Systems, Sept. 1-4, San Miniato, 
Pisa, Italy. Cosponsors: Univ. of Pisa, 

Univ. of St. Andrews (UK). Contact Anto¬ 
nio Albano, Dip. di Informatica, Univ. di 
Pisa, 56126 Pisa, Italy, fax 39 (50) 510226, 
e-mail pos5@di.unipi.it. 

Third Int’l Conf. on Algebraic and Logic 
Programming, Sept. 2-4, Pisa, Italy. Con¬ 
tact Helene Kirchner, CRIN and INRIA- 
Lorraine, BP 239, Campus Scientifique, 
54506 Vandoeuvre-les-Nancy Cedex, 
France, e-mail hkirchner@loria.crin.fr. 

Dexa 92, Third Int’l Conf. on Database 
and Expert Systems Applications, Sept. 2- 

4, Valencia, Spain. Cosponsors: Technical 
Univ. of Valencia et al. Contact Roland 
Wagner, FAW, Univ. of Linz, A4040 Linz, 
Austria, phone 43 (732) 2468-791, fax 43 
(732) 243-989, e-mail a4423dab@awiunlll. 
bitnet. 

Third Int’l Workshop on VLSI for Artifi¬ 
cial Intelligence and Neural Networks, 
Sept. 2-4, Oxford, England. Sponsor: Univ. 
of Oxford. Contact Jos6 G. Delgado-Frias, 
Electrical Eng. Dept., State Univ. of New 
York at Binghamton, Binghamton, NY 
13902-6000, phone (607) 777-4806, fax 


(607) 777-4822, e-mail delgado@bingvaxu. 
cc.binghamton.edu. 

Int’l Multiconference on Signals, Data, and 
Systems, Sept. 2-4, Chicago. Sponsor: Int’l 
Assoc, for the Advancement of Modeling 
and Simulation Tech, in Enterprises. Con¬ 
tact G. Mesnard, 16 Av. Grange Blanche, 
69160 Tassin-la-Demi-Lune, France, fax 
(33) 78-34-54-17. 

Medinfo 92, Seventh World Congress on 
Medical Informatics, Sept. 6-10, Geneva. 
Sponsor: Int’l Medical Informatics Assoc. 
Contact Symporg SA, 108 route de Fron- 
tenex, CH-1208 Geneva, Switzerland, 
phone 41 (22) 786-3744, fax 41 (22) 796- 
4080. 


Second Int’l Logic Programming Summer 
School, Sept. 7-11, Zurich. Sponsors: 
ESPRIT Computational Logic Network, 
Univ. of Zurich, Switzerland. Contact 
Norbert E. Fuchs, Computer Science 
Dept., Univ, of Zurich, 8057 Zurich, Swit¬ 
zerland, fax 41 (1) 363-0035, e-mail fuchs@ 
ifi.unizh.ch. 

Second European Modula-2 Conf., Sept. 8- 

9, Leicester, England. Sponsor: Leicester 
Polytechnic. Contact Sue Brooks, Leicester 
Polytechnic, Marketing Centre, PO Box 
143, Leicester LEI 9BH, England, phone 
44 (0533) 577-577, fax 44 (0533) 549-972; or 
M. Al-Akaida, phone 44 (0533) 577-098, 
fax 44 (0533) 577-052, e-mail mma.uk.ac. 


Workshop on Neural Networks — 
Techniques and Applications, Sept. 
7-8, Liverpool, England. Cosponsors: 

IEEE United Kingdom-Republic of Ire¬ 
land Computer Chapter et al. Contact Kat¬ 
rina Houghton, Computer Science Dept., 
Univ. of Liverpool, Liverpool L69 3BX, 
England, UK, phone 44 (51) 794-3668, fax 
44 (51) 794-3715. 


EWSPT 92, Second European Workshop 
on Software Process Tech., Sept. 7-8, 

Trondheim, Norway. Cosponsors: Assoc. 
Francaise pour la Cybernetique Econo- 
mique et Technique et al. Contact Jean- 
Claude Derniame, Centre de Recherche en 
Informatique de Nancy, Campus scienti¬ 
fique B.P. 239, F-54506 Vandoeurve Les 
Nancy, France, phone 33 (83) 413-052, fax 
33 (83) 413-079, e-mail derniame@loria. 
crin.fr. 


Euro DAC 92, European Design Au- 
tomation Conf., Sept. 7-10, Ham¬ 
burg, Germany. Cosponsors: IEEE Circuit 
and Systems Soc. et al. Contact MP Associ¬ 
ates, 7490 Clubhouse Rd., Suite 102, Boul¬ 
der, CO 80301, phone (303) 530-4562, fax 
(303) 530-4334; or A. Zylbersztejn, Bull 
SA, 121 Ave. De Malakoff, 75116 Paris, 
France, phone 33 (14) 502-9583, fax 33 (14) 
502-9307. 


® HPDC 1, First Int’l Symp. on High- 
Performance Distributed Comput¬ 
ing, Sept. 9-10, Syracuse, N.Y. Cosponsor: 
Syracuse Univ. Contact Geoffrey C. Fox, 
NPAC, Syracuse Univ., Rm. 3-131, 111 
College PI., Syracuse, NY 13244-4100, 
phone (315) 443-4741, fax (315) 443-1973, 
e-mail hpdc@nova.npac.syr.edu. 

AICS 92, Fourth Irish Conf. on Artificial 
Intelligence and Cognitive Science, Sept. 
10-11, Limerick, Ireland. Contact Kevin 
Ryan, Computer Science and Information 
Systems Dept., Univ. of Limerick, Ireland, 
phone 353 (61) 333644, fax 353 (61) 
330316, e-mail aics92@ul.ie. 


UPPL 92, Univ. Parallel Processing Lab 
Workshop, Sept. 10-11, Alta, Utah. Con¬ 
tact Lyle Bingham, Computer System Ar¬ 
chitects, 100 Library Plaza, 15 N. 100 E., 
Provo, UT 84606-3100, phone (801) 374- 
2300, fax (801) 374-2306. 

Workshop on Logic-Level Modeling for 
ASICS, Sept. 13-15, Monterey, Calif. Spon¬ 
sor: ACM Special Interest Group on De¬ 
sign Automation. Contact Mark Glasser, 
Nextware, 2339 Charleston Rd., Suite A, 
Mountain View, CA 94043, phone (415) 
691-0333. 


Congress 92,12th World Computer Con¬ 
gress, Sept. 7-11, Madrid. Sponsor: Int’l 
Federation for Information Processing. 
Contact Grupo Geyseco, Congress 92, 
Mauricio Legendre, 4-8.°G., E-28046 Mad¬ 
rid, Spain, fax 34 (1) 323-4936, e-mail 
ifip92@dit.upm.es. 

Eurographics 92, Sept. 7-11, Cambridge, 
England. Sponsor: Eurographics Assoc. 
Contact Jane Thorp, EG 92, Conf. Secre¬ 
tariat, The Registry, Univ. of East Anglia, 
Norwich NR4 7TJ, England, phone 44 
(603) 592-802, fax 44 (603) 250-035, e-mail 
eg92-organiser@uk.ac.uea.sys. 

ICIP 92, Second Singapore Int’l Conf. on 
Image Processing, Sept. 7-11, Singapore. 
Cosponsors: IEEE Singapore Section et al. 
Contact Technical Programme Chair, ICIP 
92, IEEE Singapore Section, 200 Jalan Sul¬ 
tan, #11-03 Textile Centre, Singapore 0719, 
phone (65) 291-9690, fax (65) 292-8596. 


LCN 92,17th Conf. on Local Com¬ 
puter Networks, Sept. 13-16, Minne¬ 
apolis. Sponsor: IEEE Computer Soc. 
Technical Committee on Computer Comm. 
Contact Marc Cohn, Raychem, MS 123/ 
6612, 300 Constitution Dr., Menlo Park, 
CA 94025-1164, phone (415) 361-3902, fax 
(415) 361-6248; or Steve Bell, Hughes 
LAN Systems, MS 392,1072 S. Saratoga 
Svale Rd., San Jose, CA 95129, phone 
(415) 966-7926, fax (415) 966-7990, e-mail 
sbell@hls.com. 

Fifth Digital Signal Processing Workshop, 
Sept. 13-16, Starved Rock State Park, Ill. 
Sponsor: IEEE Signal Processing Soc. 
Contact Mark J.T. Smith, School of Elec¬ 
trical Eng., Georgia Inst, of Tech., Atlanta, 
GA 30332-0250, phone (404) 894-6291. 

SESS, Software Eng. Standards 
Symp., Sept. 13-17, Brighton, UK. 
Contact Takis Katsoulakos, Lloyd’s Regis¬ 
ter, Lloyd’s Register House, 29 Wellesley 
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Rd., Croydon, CRO 2AJ, UK, phone (081) 
681-4774. 


DCCA 92, Third Working Conf. on 
Dependable Computing for Critical 
Applications, Sept. 14-16, Mondello, Sicily, 
Italy. Sponsor: Int'l Federation for Infor¬ 
mation Processing Working Group 10.4. 
Contact Carl E. Landwehr, Code 5540, Na¬ 
val Research Lab, Washington, DC 20375- 
5000, phone (202) 767-3381, fax (202) 404- 
7942; or Luca Simoncini, Dipartimento di 
Ingegneria dell’Informazione, Univ. of 
Pisa, Via Diotisalvi 2, 56100 Pisa, Italy, 
phone 39 (50) 593-443 or 550-100, fax 39 
(50) 554-342, e-mail simon@iet.unipi.it or 
simon@icnucevm.cnuce.cnr.it. 


Third Usenix Unix Security Symp., Sept. 
14-16, Baltimore, Md. Contact Usenix 
Conf. Office, 22672 Lambert St., Suite 613, 
El Toro, CA 92630, phone (714) 588-8649, 
fax (714) 588-9706, e-mail conference® 
usenix.org. 

|£gj) ICARCV 92, Second Int’l Conf. on 
Automation, Robotics, and Comput¬ 
er Vision, Sept. 15-18, Singapore. Cospon¬ 
sors: Singapore Institution of Engineers 
et al. Contact ICARCV Secretariat, Asso¬ 
ciated Conventions and Exhibitions, 204 
Bukit Timah Rd., #04-00, Boon Liew 
Bldg., Singapore 0922, phone (65) 799- 
5470, fax (65) 791-2687, e-mail emital@ 
ntuvax.bitnet. 


(iSjj IEEE Workshop on Visual Languag¬ 
es? es, Sept. 15-18, Seattle. Contact Tad- 
ao Ichikawa, Faculty of Eng., Hiroshima 
Univ., 1-4-1 Kagamiyama, Higashi-Hiro- 
shima 724, Japan, phone 81 (824) 227-029, 
fax 81 (824) 227-195. 


Sixth Int’l Conf. on Modeling Techniques 
and Tools for Computer Performance 
Modeling, Sept. 16-18, Edinburgh, Scot¬ 
land. Sponsors: Int’l Federation for Infor¬ 
mation Processing Working Group 7.3, 
British Computer Soc. Contact Margaret 
Davis, Edinburgh Univ., Edinburgh EH9 
3JZ, Scotland, phone 44 (31) 650-5128, fax 
44 (31) 667-7209, e-mail mda@cs.ed.ac.uk. 

Conf. on Control and its Applications, 
Sept. 16-18, Minneapolis. Sponsor: Soc. for 
Industrial and Applied Math. Contact 
SIAM, 3600 University City Science Cen¬ 
ter, Philadelphia, PA 19104-2688, phone 
(215) 382-9800, fax (215) 386-7999, e-mail 
siam@wharton.upenn.edu. 


Workshop on Japanese Information: Com¬ 
puters, Semiconductors, and Electronics, 
Sept. 17, Washington, D.C. Sponsor: Japan 
Information Access Project. Contact Susan 
Lusk, JIAP, 1730 Massachusetts Ave. NW, 
Washington, DC 20036, phone (202) 833- 
4545, fax (202) 728-9614, e-mail japan. 
project@compmail.com. 


WLI, IEEE Conf. on Wireless LAN 
N5? Implementation, Sept. 17-18, Day- 
ton, Ohio. Contact James T. Geier, 685 N. 
Enon Rd„ Yellow Springs, OH 45387, 
phone (513) 255-6224. 


KBSE 92, Seventh Knowledge-Based 
vi? Software Eng. Conf., Sept. 20-23, Ty¬ 
sons Corner, Va. Sponsor: Rome Lab. 
Contact W. Lewis Johnson, USC Informa¬ 
tion Sciences Inst., 4676 Admiralty Way, 
Marina del Rey, CA 90292-6695, phone 
(310) 822-1511, fax (310) 823-6714, e-mail 
johnson@isi.edu; or Barbara Radzisz, Data 
and Analysis Center for Software, PO Box 
120, Utica, NY 13503, phone (315) 336- 
0937, kbse7-request@cs.rpi.edu. 

/£§^) ITC 92,1992 Int’l Test Conf., Sept. 

20-24, Baltimore. Cosponsor: IEEE 
Philadelphia Section. Contact Doris 
Thomas, 514 Pleasant Valley Blvd., Suite 
3, Altoona, PA 16602, phone (814) 941- 
4666, fax (814) 941-4668. 

ASIC 92, Fifth IEEE Int’l Conf. on Appli¬ 
cation-Specific Integrated Circuits, Sept. 
21-25, Rochester, N.Y. Sponsor: IEEE 
Rochester Section. Contact Lynne M. En- 
gelbrecht, 170 Mt. Read Blvd., Rochester, 
NY 14611, phone (716) 328-2310, fax (716) 
436-9370; or Y. Tim Tsia, Eastman Kodak, 
MC-02015,1669 Lake Ave., Bldg. 81.454/ 
KRL, Rochester, NY 14650-2015, phone 
(716) 722-4896, fax (716) 722-9053. 

® Compsac 92,16th Int’l Computer 
Software and Applications Conf., 
Sept. 22-25, Chicago. Contact Stephen 
Yau, Univ. of Florida, CIS Dept., Rm. 301, 
Gainesville, FL 32611, phone (904) 335- 


tgfjb PRICAI, Second Pacific Rim Int’l 
vl? Conf. on Artificial Intelligence, Sept. 
23-25, Sungdong-ku, Korea. Cosponsors: 
Korea Information Science Soc. et al. Con¬ 
tact Jim Hyung Kim, Korea Advanced 
Inst, for Science and Tech., Center for Ar¬ 
tificial Intelligence Research, 373-1 Ku- 
song-dong, Yusong-ku, Taejon, 305-701, 
Korea, phone 82 (42) 829-3517, fax 82 (42) 
829-8700, e-mail jkim@cair.kaist.ac.kr. 

DT 92, Int’l Conf. on Data Transmis- 
N§? sion, Sept. 23-25, London. Sponsor: 
Institution of Electrical Engineers. Contact 
Alan Clark, Dowty Communications, May- 
ze House, Westmead, Swindown SN5 7YT, 
phone 44 (0793) 511-789, fax 44 (0793) 
511-683. 

IWOOOS 92, Int’l Workshop on 
el? Object Orientation in Operating Sys¬ 
tems, Sept. 24-25, Paris. Sponsor: Institut 
National de Recherche en Informatique 
et en Automatique. Contact Roy Camp¬ 
bell, Univ. of Illinois, Computer Science 
Dept., 2413 Digital Lab, 1304 W. Spring- 
field, Ave., Urbana, IL 61801, phone (217) 
333-0215 or 3328, fax (217) 333-3501, 
e-mail roy@cs.uiuc.edu or eric.diku.dk. 

13th Int’l Symp. on Electronics Manufac¬ 
turing Tech., Sept. 28-30, Baltimore. Co¬ 
sponsors: IEEE Components, Hybrids, and 
Manufacturing Tech. Soc., Electronic In¬ 
dustries Assoc. Contact Bill Moody, 2529 
Eaton Rd., Wilmington, DE 19810, phone 
(302) 478-4143, fax (302) 478-7057. 


tfQl Graphicon, Computer Graphics in 
vi? Science and Arts, Sept. 28-Oct. 3, 

Moscow, Russia. Cosponsor: ACM. Con¬ 
tact Yury Golubev, Keldysh Inst, of Ap¬ 
plied Math, Miusskaya Sq. 4, Moscow 
125047, Russia, phone (095) 250-7817. 

Int’l Workshop on Hardware- 
V&Z Software Codesign, Sept. 30-Oct. 2, 

Estes Park, Colo. Cosponsors: IEEE Com¬ 
puter Soc. et al. Contact Joanne E. 
DeGroat, Ohio State Univ., 205 Dreese 
Lab, 205 Neil Ave., Columbus, OH 43210, 
phone (614) 292-2439, e-mail degroat@ee. 
eng.ohio-state.edu; or Alfred E. Dunlop, 
AT&T Bell Labs, 600 Mountain Ave., 
Murray Hill, NJ 07974, phone (908) 582- 
6570, e-mail aed@allegra.att. com. 


October 1992 

Second Int’l Workshop on Respon¬ 
ds? s j ve Computer Systems, Oct. 1-2, 

Saitama, Japan. Sponsor: US Office of Na¬ 
val Research. Contact Miroslaw Malek, 
Electrical and Computer Eng. Dept., Univ. 
of Texas, Austin, TX 78712, phone (512) 
471-5704, fax (512) 471-0954, e-mail 
malek@emx. utexas.edu; or Tohru Kikuno, 
Information and Computer Science Dept., 
Osaka Univ., 1-1, Machikaneyama-cho, 
Toyonaka-shi, Osaka, 560, Japan, phone 81 
(6) 844-1151, fax 81 (6) 841-9741, e-mail 
kikuno@ics.osaka-u.ac.jp. 

Sixth Software Eng. Inst. Conf. on 
vi? Software Eng. Education, Oct. 5-6, 
and 11th SEI Educator Development 
Workshop, Oct. 7, San Diego, Calif. Co¬ 
sponsor: Software Eng. Inst. Contact Carol 
Sledge, SEI, Carnegie Mellon Univ., Rm. 
4206, Pittsburgh, PA 15213-3890, phone 
(412) 268-7708, fax (412) 268-5758, e-mail 
cas@sei.cmu.edu. 

/jjji 11th Symp. on Reliable Distributed 

vi? Systems, Oct. 5-7, Houston. Cospon¬ 
sors: IEEE Computer Soc. Technical Com¬ 
mittee on Distributed Processing et al. 
Contact Thomas F. Lawrence, Rome Lab/ 
C3AB, Bldg. 3, Griffiss Air Force Base, 

NY 13441, phone (315) 330-2158, fax (315) 
330-3911; or Kishor S. Trivedi, Electrical 
Eng. Dept., Duke Univ., Durham, NC 
27706, phone (919) 660-5269, e-mail kst@ 
egr.duke.edu. 

|£f£) ISSRE 92, Third Int’l Symp. on Soft- 
ware Reliability Eng., Oct. 7-9, Re¬ 
search Triangle Park, N.C. Cosponsors: 
IEEE Computer Soc. Technical Commit¬ 
tee on Software Eng. et al. Contact Mladen 
A. Vouk, Computer Science Dept., Box 
8206, North Carolina State Univ., Raleigh, 
NC 27695-8206, phone (919) 515-7886, fax 
(919) 515-5839, e-mail vouk@adm.csc.ncsu. 

Parallel Software Eng. Standards 
ei? Seminars, Oct. 8-9, San Diego, Calif. 
Sponsor: IEEE Computer Soc. Software 
Eng. Standards Subcommittee. Contact D. 
Vera Edelstein, Nynex Science and Tech., 
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500 Westchester Ave., White Plains, NY 
10604, phone (916) 644-2888, fax (916) 
644-2963, e-mail vera@nynexst.com. 

Milcom 92, Oct. 11-14, San Diego, Calif. 
Cosponsors: IEEE Comm. Soc. et al. Con¬ 
tact Milcom 92, General Dynamics Elec¬ 
tronics Div., PO Box 85106, San Diego, 

CA 92186-5106; Security Dept. MZ 7101- 
G, Milcom 92, General Dynamics Elec¬ 
tronics Div., PO Box 85227, San Diego, 

CA 92186-5227; or Dennis E. Litchfield, 
Office of the Assistant Secretary of De¬ 
fense (C 3 I), The Pentagon, Rm. 3D 228, 
Washington, DC 30301-3040. 

ICCD 92, Int'l Conf. on Computer 

Design, Oct. 12-14, Cambridge, 

Mass. Cosponsor: IEEE Circuit and Sys¬ 
tems Soc. Contact IEEE Computer Soc., 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013, fax 
(202) 728-0884. 

ASPLOS 5, Fifth Conf. on Architec¬ 
ts^ tural Support for Programming Lan¬ 
guages and Operating Systems, Oct. 12-15, 

Boston. Sponsor: ACM. Contact Barry 
Flahive, Hewlett-Packard, Apollo Systems 
Div., 300 Apollo Dr., MS CHR 02 DE, 
Chelmsford, MA 01824, phone (508) 256- 
2471 or 6600, e-mail flahive@apollo.hp. 


Mk] Seventh Int’l Software Process 

Workshop, Oct. 15-18, Yountville, 
Calif. Sponsor: Rocky Mountain Inst, of 
Software Eng. Contact Ian Thomas, Soft¬ 
ware Design and Analysis, 444 Castro St., 
Suite 413, Mountain View, CA 94041, 
phone (415) 694-1464. 

OOPSLA 92, Seventh Conf. on Object- 
Oriented Programming Systems, Languag¬ 
es, and Applications, Oct. 18-22, Vancou¬ 
ver, B.C., Canada. Sponsor: ACM. Contact 
John Pugh, School of Computer Science, 
Carleton Univ., Colonel By Drive, Ottawa, 
Ont., Canada K1S 5B6, phone (613) 788- 
4330, e-mail oopsla92@carleton.ca. 

Frontiers 92, Fourth Symp. on the 

Frontiers of Massively Parallel Com¬ 
putation, Oct. 19-21, McLean, Va. Cospon¬ 
sors: NASA Goddard Space Flight Center 
et al. Contact Pearl Wang, Computer Sci¬ 
ence Dept., George Mason Univ., 440 Uni¬ 
versity Dr., Fairfax, VA 22030-4444, phone 
(703) 993-1527, fax (703) 993-1521. 

/£§j\ Visualization 92, Oct. 19-23, Boston. 

Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Computer Graphics. 
Contact Bruce E. Brown, Oracle, 500 Ora¬ 
cle Pkwy., Box 659412, Redwood Shores, 
CA 94065, phone (415) 506-6202, fax (415) 
726-0983; or Gregory M. Nielson, Arizona 
State Univ., Rural Rd. and University 
Ave., Tempe, AZ 85287-5406, phone (602) 
965-2785, e-mail nielson@enuxva.eas.asu. 


FOCS, Foundations of Computer 
Science, Oct. 25-27, Pittsburgh. Con¬ 
tact Gary Miller, School of Computer Sci¬ 
ence, Carnegie Mellon Univ., Pittsburgh, 


26th Asilomar Conf. on Signals, Sys- 

terns, and Computers, Oct. 26-28, Pa¬ 
cific Grove, Calif. Cosponsors: Naval Post¬ 
graduate School et al. Contact Neil K. Jab- 
Ion, AT&T Bell Labs, 200 Laurel Ave., 
Rm. 1G-540, Middletown, NJ 07748-4801, 
phone (908) 957-2011, fax (908) 957-7943, 
e-mail nkj@mtqub.att.com. 

Fifth Workshop on Software Reuse, 
N&7 Oct. 26-29, Palo Alto, Calif. Cospon¬ 
sor: IEEE Computer Soc. Technical Com¬ 
mittee on Software Eng. Contact Martin 
Griss, Hewlett-Packard Labs, 1501 Page 
Mill Rd., Palo Alto, CA 94304-1126, phone 
(415) 857-8715, fax (415) 857-8526, e-mail 
griss@hpl.hp.com. 

Fourth NASA Symp. on VLSI Design, 

Oct. 29-30, Coeur d’Alene, Idaho. Cospon¬ 
sors: Spokane, Washington, IEEE Section, 
Univ. of Idaho NASA Space Eng. Re¬ 
search Center. Contact Sterling Whitaker, 
NASA SERC, Univ. of Idaho, Moscow, ID 
83843, phone (208) 885-6500, fax (208) 
885-6840, e-mail swhitaker@grieg.mrc. 
uidaho.edu. 


November 1992 

ISOS 7, Seventh Int’l Symp. on 
Computer and Information Sciences, 
Nov. 2-4, Antalya, Turkey. Cosponsors: 
IEEE Computer Soc. Turkey Chapter 
et al. Contact Erol Gelenbe, Ecole des 
Hautes Etudes en Informatique, 45 rue des 
Saints-Peres, 75006 Paris, France, phone 33 
(1) 4286-2136, fax 33 (1) 4286-2231, e-mail 
erol@ehei.ehei.fr; or Nese Yalabik, Com¬ 
puter Eng. Dept., Middle East Technical 
Univ., 06531 Ankara, Turkey, phone 90 (4) 
223-7100, ext. 2079, fax 90 (4) 286-8624, 
e-mail iscis@trmetu.bitnet. 

IJCNN 92, Int’l Joint Conf. on Neural Net¬ 
works, Nov. 3-6, Beijing, China. Cospon¬ 
sors: IEEE Neural Networks Council et al. 
Contact IJCNN 92 Secretariat, Rm. 2307, 
13th Floor, 12 Nongzhanguan Nanlu, Bei¬ 
jing, 100026, China, fax 86 (1) 500-5233. 

(jgjj) DFT 92,1992 IEEE Int’l Workshop 
VS/ on Defect and Fault Tolerance in 
VLSI Systems, Nov. 4-6, Dallas. Contact 
D.M.H. Walker, Electrical and Computer 
Eng. Dept., Carnegie Mellon Univ., Pitts¬ 
burgh, PA 15213-3890, phone (412) 268- 
8522, fax (412) 268-2860, e-mail dmw@ 

v -ft) Workshop on High-Level Synthesis, 
Nov. 4-6, Dana Point, Calif. Contact 
Wolfgang Rosensteil, Forschumrtzentrum 
Informatik, Germany, phone 49 (721) 
6906-401, fax 49 (721) 6906-409. 

CIKM 92, First Int’l Conf. on Infor- 
NS7 mation and Knowledge Management, 
Nov. 8-11, Baltimore. Sponsor: Int’l Soc. of 
Mini- and Microcomputers. Contact Timo¬ 


thy W. Finin, Tony Nircio, or Yelena Ye- 
sha, C/S Dept., Univ. of Maryland, 5401 
Wilkens Ave., Baltimore, MD 21228-5398, 
phone (410) 455-3000 or 3522, fax (410) 
455-3969, e-mail cikm@cs.umbc.edu. 

ICCAD 92, Int’l Conf. on Computer- 
Aided Design, Nov. 8-12, Santa 
Clara, Calif. Cosponsors: IEEE Circuit and 
Systems Soc., ACM. Contact MP Associ¬ 
ates, 7490 Clubhouse Rd., Suite 102, Boul¬ 
der, CO 80301, phone (303) 530-4562, fax 
(303) 530-4334; or Harry Stephanov, Cen¬ 
ter for Information and Robotics, Rens¬ 
selaer Polytechnic Inst., Troy, NY 12181, 
phone (518) 276-6156. 

|£§j!) CSM 92,1992 Conf. on Software 
viz Maintenance, Nov. 9-12, Orlando, 
Fla. Contact Vaclav Rajlich, Computer Sci¬ 
ence Dept., Wayne State Univ., Detroit, 

MI 48202, phone (313) 577-5423, fax (313) 
577-6868, e-mail vtr@cs.wayne.edu. 

Systems Test and Diagnosis Work- 
shop, Nov. 9-12, Freiburg, Germany. 
Contact Colin Maunder, BT Labs, Martle- 
sham Heath, Ipswich IP5 7RE, UK, phone 
44 (473) 642-706, fax 44 (473) 642-157. 

(j[§^ TAI 92, Fourth Int’l IEEE Conf. on 
vU' Tools with Artificial Intelligence, 
Nov. 10-13, Arlington, Va. Contact Niko- 
laos G. Bourbakis, SUNY at Binghamton, 
Electrical Eng. Dept., Binghamton, NY 
13902-6000, phone (607) 777-4856 or 2165, 
fax (607) 777-4822, e-mail bourbaki@ 
bingvaxu.cc.binghamton.edu. 

vNj Second Workshop on Management 
viz of Replicated Data, Nov. 12-13, 

Monterey, Calif. Sponsor: IEEE Computer 
Soc. Technical Committee on Operating 
Systems and Application Environments. 
Contact Jehan-Francois Paris, Computer 
Science Dept., Univ. of Houston, 4800 Cal¬ 
houn Rd., Houston, TX 77204-3475, phone 
(713) 749-3943, fax (713) 749-2378, e-mail 
paris@ cs.uh.edu. 

Third Int’l Workshop on Network 
and Operating System Support for 
Digital Audio and Video, Nov. 12-13, La 

Jolla, Calif. Cosponsor: IEEE Comm. Soc. 
Contact P. Venkat Rangan, Multimedia 
Lab, Computer Science Dept., Univ. of 
California at San Diego, La Jolla, CA 
92093-0114, phone (619) 534-5419, fax 
(619) 534-7029, e-mail venkat@cs.ucsd.edu. 

/(§)\ Supercomputing 92, Fifth High- 
v5z Performance Computing and Comm. 
Conf., Nov. 16-20, Minneapolis. Cospon¬ 
sor: ACM. Contact IEEE Computer Soc., 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013, fax 
(202) 728-0884. 

/jjj\ ATS 92, First Asian Test Symp., 
viz Nov. 26-27, Hiroshima, Japan. Con¬ 
tact Hideo Fujiwara, Computer Science 
Dept., Meiji Univ., 1-1-1 Higashimita, 
Tama-ku, Kawasaki 214, Japan, fax 81 (44) 
934-7912, e-mail fujiwara@cs.meiji.ac.jp; or 
Kozo Kinoshita, Applied Science Dept., 
Osaka Univ., 2-1 Yamadaoka, Suite 565, 
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Japan, phone 81 (06) 877-5111, fax 81 (06) 
877-2900. 


^3^ WACV, IEEE Workshop on Appli- 
cations of Computer Vision, Nov. 30- 
Dec. 2, Palm Springs, Calif. Contact Bir 
Bhanu, College of Eng., Univ. of Califor¬ 
nia, Riverside, CA 92521-0425, phone 
(714) 787-3954, fax (714) 787-3188. 

ACSAC 92, Eighth Computer Secu- 
rity Applications Conf., Nov. 30-Dec. 

4, San Antonio, Texas. Cosponsors: Aero¬ 
space Computer Security Associates et al. 
Contact Ronald Gove, Booz-Allen and 
Hamilton, 4330 East-West Hwy., Bethesda, 
MD 20814, phone (301) 951-2395, fax (301) 
907-4302, e-mail gove@dockmaster.ncsc.mil. 


December 1992 

|£§j\ IEEE Workshop on Imprecise and 
Approximate Computation, Dec. 1, 

Phoenix, Ariz. Cosponsors: IEEE Comput¬ 
er Soc. Technical Committee on Real- 
Time Systems et al. Contact Wei Zhao, 
Computer Science Dept., Texas A&M 
Univ., College Station, TX 77843-3112, 
phone (409) 845-5098, fax (409) 847-8578, 
e-mail zhao@cs.tamu.edu. 

/jQjj) Micro 25, 25th Int’l Symp. on Micro- 
architecture, Dec. 1-4, Portland, Ore. 
Cosponsors: IEEE Computer Soc. Techni¬ 
cal Committee on Microprogramming and 
Microarchitecture, ACM. Contact Wen- 
mei W. Hwu, Electrical and Computer 
Eng. Dept., Univ. of Illinois, 1101 W. 
Springfield Ave., Urbana, IL 61801, phone 
(217) 244-8270, fax (217) 244-5686, e-mail 
hwu@crhc.uiuc.edu. 

Ninth TRON Project Symp., Dec. 1- 

4, Tokyo. Sponsor: TRON Assoc. 
Contact Koji Nihei, Oki Electric Industry 
Co., 7-12 Toranomon, 1-Chome, Minato- 
ku, Tokyo 105, Japan, phone 81 (3) 3501- 
3111, fax 81 (3) 3581-3349; or Eiichi Ohno, 
Headquarters R&D, Mitsubishi Electric 
Corp., 2-2-3 Marunouchi, Tokyo 100, Ja¬ 
pan, phone 81 (3) 3218-2163, fax 81 (3) 
3218-2188. 

Fourth IEEE Symp. on Parallel and 
Distributed Processing, Dec. 1-4, Ar¬ 
lington, Texas. Cosponsor: IEEE Dallas 
Section. Contact Hal Sudborough, Com¬ 
puter Science Dept., Univ. of Texas at Dal¬ 
las, Richardson, TX 75083, phone (214) 
690-2184, e-mail hal@utdallas.edu; or A.R. 
Hurson, Electrical and Computer Eng. 
Dept., Penn State Univ., University Park, 
PA 16802, phone (814) 863-1187, fax (814) 
865-7065, e-mail a2h@ccl.psu.edu. 

RTSS 92,13th IEEE Real-Time Sys- 
terns Symp., Dec. 2-4, Phoenix, Ariz. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Real-Time Computing. 
Contact Lui Sha, Software Eng. Inst., Car¬ 
negie Mellon Univ., 5000 Forbes Ave., 
Pittsburgh, PA 15213, phone (412) 268- 
5875, fax (412) 268-5758. 
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GOING ONUNE 


The New World Of Multimedia Documentation 


SIGDOC’92: The 10th Annual 
International Conference 

October 13 to 16, 1992 

The Westin Hotel, Ottawa, Canada 


SIGDOC’92 is a conference that will examine design, 
process, quality, tools, applications, costs and benefits 
of multimedia documentation. SIGDOC’92 will feature: 


■ a keynote address by Theodor Holm Nelson 

■ pre-conference tutorials such as 
Bill Horton’s “Visual Literacy" 

■ presentations about multimedia projects 
and research results 

• a demonstration area 


Join us as we venture into the new world of multimedia 
documentation! Register before September 1, 1992, 
and qualify for early registration prizes. 


For more information: 

Telephone: (613) 763-2134 
Fax: (613) 763-2626 

INTERNET address: SIGDOC92@BNR.CA 


Sponsored by The Association for Computing Machinery, 
Special Interest Group on Documentation in cooperation 
with Northern Telecom and Bell-Northern Research Limited 
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Software Platforms 

Systems Developers/Systems Engineers 

Come join a $380 million worldwide provider of information management 
solutions. Cincinnati Bell Information Systems (CBIS) is seeking 
individuals with a solid background in C/UNIX to apply an open-system platforms 
approach to develop new CBIS Edge sm software products for our clients. 

The new CBIS Edge represents an area of unlimited personal and 
professional growth opportunities for select individuals in our Software 
Development Centers in Cincinnati, suburban Chicago, and Orlando. 
Competitive systems development and systems engineering candidates will 
have three or more years’ experience in one or more of the following: C++, 
Object-Oriented Programming, Open-Systems Architecture, Case Tools, and 
Requirements Definition and Analysis. 


CBIS provides merit-based compensation plans, relocation assistance, 
“FLEX” benefits, 401(k) savings plan, and tuition reimbursement Please mail 
your resume to CBIS, P.O. Box 1638, Dept. CD392, Cincinnati, OH 
45201, ATTN: Steve Suiter, I 


Director of Organizational 
Development. 

.' We are an Equal Opportunity/Affirmative Action Employer. 
Edge is a service mark of CBIS. 














CAREER OPPORTUNITIES 


RATES: $15.00 per line (ten lines 
minimum). Average five typeset words 
per line, eight lines per column inch. Add 
$10 for box number. Send copy at least 
one month prior to publication date to: 
Marian B. Tibayan, Classified 
Advertising, COMPUTER Magazine, 
10662 Los Vaqueros Circle, PO Box 
3014, Los Alamitos, CA 90720-1264; 
(714) 821-8380; fax: (714) 821-4010. 

In order to conform to the Age Discrimina¬ 
tion in Employment Act and to discourage 
age discrimination, COMPUTER may re¬ 
ject any advertisement containing any of 
these phrases or similar ones: “...recent 
college grads...,” “...1-4 years maximum 
experience...,” “...up to 5 years experi¬ 
ence,” or “...10 years maximum experi¬ 
ence." COMPUTER reserves the right to 
append to any advertisement without spe¬ 
cific notice to the advertiser. Experience 
ranges are suggested minimum require¬ 
ments, not maximums. COMPUTER as¬ 
sumes that since advertisers have been 
notified of this policy in advance, they 
agree that any experience requirements, 
whether stated as ranges or otherwise, will 
be construed by the reader as minimum re¬ 
quirements only. COMPUTER encour¬ 
ages employers to offer salaries that are 
competitive, but occasionally a salary may 
be offered that is significantly below cur¬ 
rently acceptable levels. In such cases the 
reader may wish to inquire of the employer 
whether exten t ng c nstan e ipply. 


SOFTWARE TEST ENGINEER 

Software Test Engineer for firm in NE 
Ohio. Testing and reviewing software de¬ 
signs, specifications, and procedures as a 
member of the Test Engineering Group. This 
involves working closely with the software 
development engineers in order to ensure 
that all errors and “bugs” have been eli¬ 
minated before a software product is re¬ 
leased to customers. In particular, the Test 
Engineering Group will develop and imple¬ 
ment automated testing procedures using 
such software test techniques as black box 
test, white box test and regression test. Must 
have M.S. (or ABT) in Computer Science or 
Electrical Engineering. Academic program 
must have included one course each in the 
following areas: Algorithm Analysis, Com¬ 
puter Architecture, Logic Programming, 
Database and File Management Technology, 
and Computer Networks. As evidenced by 
academic letter(s) of reference and/or em¬ 
ployer testimonials, must have the ability to 
utilize black box, white box, and regression 
tests in testing software. Must have four 
months of experience as software engineer. 
Experience must have been in testing 
software. 40 hrs/wk, 8:00am-5:00pm, 
$36,000/yr. Must have proof of legal 
authority to work permanently in U.S. Send 
resume and course transcript in duplicate 
to L. Ellison, J.O. # 12008800, Ohio Bureau 
of Employment Services, P.O. Box 1618, 
Columbus, Ohio 43216. 


UNIVERSITY OF HEIDELBERG 

The Faculty for Physics and Astronomy 
invites applications for a C3-Professorship 
for Image Processing. The position is to 
be filled at the earliest possible date. 

The successful applicant will be participa¬ 
ting in the program of the Interdisciplinary 
Center for Scientific Computing. Research 
activities will take place in close cooperation 
with other groups at the university being 
active in the field of applied digital image pro¬ 
cessing. Participation in the teaching pro¬ 
gram of the Faculty for Physics and Astro¬ 
nomy is expected. 

Applications (ind. CV and list of publica¬ 
tions) should be sent to the Dekan der 
Fakultat fur Physik und Astronomie, Albert- 
Uberle-Str. 11. W-6900 Heidelberg. Appli¬ 
cation deadline is the 30th of September, 
1992. As the faculty is interested to enlarge 
and number of female faculty members, 
qualified women are encouraged to apply. 


VICE PRESIDENT OF SOFTWARE 
DEVELOPMENT AND SALES 

Direct, coordinate and exercise functional 
authority for planning, organization, control 
and integration of the company’s overall 
software design, sale and implementation for 
major customers. Consult with key clients to 
determine information requirements, boun¬ 
daries and priorities of new projects, system 
capacity and equipment acquisitions. Direct 
and coordinate the customized software de¬ 
velopment and marketing activities of the 
company, utilizing advanced and specialized 
knowledge of IBM’s software products and 
their capabilities. Direct the design and im¬ 
plementation of software customization by 
consulting staff as negotiated under con¬ 
sulting service contracts to meet clients 
specific needs and equipment configura¬ 
tions. Requires a Bachelor’s in Computer 
Science or Management Information Sys¬ 
tems. Six years in job offered or six years 
directly related software development and 
sales experience. Or will consider eight years 
experience in job offered or eight years 
directly related software development and 
sales experience in lieu of degree and six 
years experience. Included in the six years 
experience, must have at least five years of 
working with software products and man¬ 
agement experience in software develop¬ 
ment/sales and two years experience work¬ 
ing with operating systems such as DOS, 
OS, MVS, VM and DB2, SQL, AS, PAS, 
and Executive Decisions, Sales background 
must include at least two years experience in 
sale of computer software, consulting ser¬ 
vices and education/training of clients’ staff. 
40 hour work week. $60,000.00 per year. 
Apply at the Texas Employment Commis¬ 
sion, Dallas, Texas or send resumes to the 
Texas Employment Commission, TEC Build¬ 
ing, Austin, Texas 78778. Job Order 
<'6521686. Ad paid by an Equal Employ¬ 
ment Opportunity Employer. 


OREGON STATE UNIVERSITY 

Department of Computer Science 

The Department of Computer Science in¬ 
vites applicants for tenure-track positions for 
Assistant or Associate Professor, to start in 
September, 1992 or thereafter. Specializa¬ 
tion in software, artificial intelligence, parallel 
computing, or computer graphics is desir¬ 
able, but all qualified applicants will be con¬ 
sidered. Applicants should have completed 
or expect to complete all requirements for 
a Ph.D. in computer science or a closely 
related field and should have demonstrated 
research and teaching potential. Candidates 
for senior positions should have established 
research reputations. Review of applications 
will begin July 1, 1992, and will continue 
until the positions are filled. Application from 
women and minorities are particularly en¬ 
couraged. Please send vita, statement of 
research interests and plans, and three letters 
of reference to: Walter G. Rudd, Chairman, 
Department of Computer Science, 303 Dear¬ 
born Hall, Oregon State University, Corvallis, 
OR 97331; email rudd@cs.orst.edu. 

Oregon State University is an equal op¬ 
portunity affirmative action employer and 
complies with Section 504 of the Rehabilita¬ 
tion Act of 1973. OSU has a policy of being 
responsive to the needs of dual-career 
couples. 


SOFTWARE JOBS ABROAD 

The International Computer Professional 
Associaton provides you with the worldwide 
contacts and up-to-the-moment information 
you need to find an exciting software assign¬ 
ment in Paris, London, and many other 
cities around the world. For more informa¬ 
tion about this new network of international 
opportunities call us at (415) 695-7618, 
24 hours/day. 


D.E. SHAW & CO. 

Algorithmic Trading 

D.E. Shaw & Co. is a small (several dozen 
employees), highly capitalized (over $300 
million in partners’ equity), extremely suc¬ 
cessful Wall Street firm specializing in quan¬ 
titative finance and computational trading. 
Computer scientists and system designers 
form the professional core of the firm, and 
not merely its support staff, and participate in 
its profits. Our technical staff includes both 
Ph.D.-level researchers recruited from Stan¬ 
ford, MIT, and other leading computer sci¬ 
ence departments and extraordinarily talented 
B.S.-and M.S.-level system designers and 
“superhackers”. It is our practice to compen¬ 
sate unusually gifted individuals at a level ex¬ 
ceeding that of the market. Applicants should 
send resumes to The Recruiting Depart¬ 
ment, D.E. Shaw & Co., 39th Floor, Tower 
45,120 W. 45th St., New York, NY 10036. 
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UNIVERSITY OF TENNESSEE 
Position available at the 
Oak Ridge National Laboratory 

The Computer Science Department at the 
University of Tennessee and the Mathemati¬ 
cal Sciences Section at Oak Ridge National 
Laboratory have two postdoctoral research 
positions available in the areas of network¬ 
ing, computational science, and database/ 
filesystem management. The University of 
Tennessee and Oak Ridge National Labora¬ 
tory are engaged in a DARPA-funded re¬ 
search project to develop a next-generation 
software distribution system. The new sys¬ 
tem is intended to be a successor to the 
NETLIB and XNETLIB software distribution 
systems. The principal investigators of the 
project are Jack Dongarra of the University 
of Tennessee and Oak Ridge National La¬ 
boratory, and Tom Rowan of Oak Ridge Na¬ 
tional Laboratory. 

Familiarity with network computing, data¬ 
bases, X-window applications, parallel ar¬ 
chitectures, and scientific computing ex¬ 
perience are desired. Benefits of the position 
include a competitive salary, travel oppor¬ 
tunities, access to state-of-the-art computa¬ 
tional facilities (including both parallel ar¬ 
chitectures and high-performance worksta¬ 
tions), and collaborative research oppor¬ 
tunities in a very active research program in 
advanced scientific computing. 

Inquiries should be directed to: Jack Don¬ 
garra, Computer Science Department, Uni¬ 
versity of Tennessee, Knoxville, TN 37996- 
1301; (615) 974-8295 (phone); (615) 974- 
8296 (fax); dongarra@cs.utk.edu (e-mail). 

The University of Tennessee and Oak 
Ridge National Laboratory are equal oppor¬ 
tunity/affirmative action employer. 


PARALLEL SCIENTIFIC SOFTWARE 
Oak Ridge National Laboratory 
and University of Tennessee 

A postdoctoral research position is avail¬ 
able in parallel scientific software at Oak 
Ridge National Laboratory and the University 
of Tennessee to work on high level techni¬ 
ques for programming a heterogeneous net¬ 
work of computers. 

The position requires experience in the 
development of X-window applications, 
parallel computing and scientific program¬ 
ming. Familiarity with network computing 
and parallel architectures is also desired. 
Benefits of the position include a competitive 
salary, travel opportunities, access to state- 
of-the-art computational facilities and col¬ 
laborative research opportunities in a very 
active research program in advanced scien¬ 
tific computing. 

Inquiries should be directed to: 

Dr. R.F. Sincovec, Head 
Mathematical Sciences Section 
Oak Ridge National Laboratory 
Dept. IEEE-08 
P.0. Box 2008, Bldg. 6012 
Oak Ridge, TN 37831-6367 
ORNL is a multi-program laboratory, 
managed by Martin Marietta Energy Sys¬ 
tems, Inc. for the US Department of Energy. 
ORNL is an affirmative action/equal oppor¬ 
tunity employer. 


UNITED STATES 
AIR FORCE ACADEMY 
Department of Computer Science 
Visiting Faculty Position 

The Department of Computer Science of 
the United States Air Force Academy invites 
applications for a Visiting Professor/Associate 
Professor/Assistant Professor position. We 
seek qualified applicants with extensive ex¬ 
perience teaching computer science and a 
record of scholarly activity. Duties will in¬ 
clude teaching undergraduate courses, re¬ 
viewing our academic program, and pro¬ 
moting undergraduate and faculty research. 
Applicant must be a U.S. citizen and should 
have a demonstrated commitment to under¬ 
graduate computer science programs. Appli¬ 
cant must be currently affiliated with an in¬ 
stitution of higher education or be a local, 
state, or federal employee. The appointment 
is normally for one year and will begin July 
1993. Salary is commensurate with your 
current salary level. To apply, please send 
your vita by 1 September 1992 to: Chairman, 
Department of Computer Science, United 
States Air Force Academy, USAF Academy, 
CO 80840-5701. 


UNITED STATES MILITARY ACADEMY 
Visiting Professor in Computer Science 

Applications are invited for AY 1992-1993 
for appointment consideration under the pro¬ 
visions of the Intergovernmental Personnel 
Act of 1979. Applicants must have Ph.D., 
possess strong commitment to undergraduate 
teaching, and currently hold the academic ap¬ 
pointment of professor or associate professor. 
Duties include teaching in, and providing ad¬ 
vice on, the Academy’s computer science 
programs. Compensation is usually commen¬ 
surate with that currently being received. Send 
resumes to Colonel Daniel M. Litynski, 
Department of Electrical Engineering and 
Computer Science, United States Military 
Academy, West Point, NY 10996. Applica¬ 
tions must be received by 1 October 1992. 
The US Military Academy is an affirmative ac¬ 
tion/equal opportunity employer. 


UNIVERSITY OF 
WISCONSIN-MADISON 
Faculty Position 

The Department of Electrical and Com¬ 
puter Engineering invites applications for 
a possible tenure or tenure-track position. 
APh.D. degree is required, and the success¬ 
ful candidate is expected to establish a strong 
research program and participate in a high 
quality instructional program. Applicants in 
all areas of computer engineering are invited 
to apply. Rank and salary will be commen¬ 
surate with qualifications and experience. 
Send resume and names of three references 
to Bahaa E.A. Saleh, Chairman, Depart¬ 
ment of Electrical and Computer Engineer¬ 
ing, University of Wisconsin -Madison, 1415 
Johnson Drive, Madison, WI 53706, an 
equal opportunity/affirmative action 
employer. 

Names, titles and/or occupations, and ad¬ 
dresses of applicants and nominees cannot be 
kept confidential. 


COMPUTER RESEARCH SCIENTIST 

Designs multidatabase language that will 
meld relational database systems with object- 
oriented database systems. Designs multi¬ 
database query language based on object- 
oriented data model and relational data 
model. Develops query processing architec¬ 
ture for query language. Designs and imple¬ 
ments query processing subsystem of multi¬ 
database system based on query processing 
architecture. Must have completed course 
requirements for Ph.D. and have 2 years ex¬ 
perience in computer related teaching, com¬ 
puter science or computer programmer (aca¬ 
demic or employment). Strong academic or 
industrial training in the theory and imple¬ 
mentation of relational database systems, 
object-oriented databases, heterogeneous 
distributed database view integration and 
database language design. Special emphasis 
on query processing techniques and archi¬ 
tecture, and intelligent query understanding. 
Special emphasis on object-oriented data 
modeling and object-oriented query model¬ 
ing. Strong ability to program in C program¬ 
ming language and Unix operating system. 
One strong reference. 40 hours per week. 
8:00 a.m. to 5:00 p.m. $961 per week. Ap¬ 
ply at the Texas Employment Commission, 
Austin, Texas, or send resume to the Texas 
Employment Commission, TEC Building, 
Austin, Texas 78778, J.O. <'6717821. Ad 
Paid by an Equal Employment Opportunity 
Employer. 


SOUTHERN CONNECTICUT 
STATE UNIVERSITY 
Computer Science 

Assistant Professor position for the spring 
of 1993 with an approximate annual salary 
of $35,000 pending funding of the position. 
This is a tenure track position teaching Com¬ 
puter Science courses at all levels including 
introductory, non-major and evening classes. 
SCSU is primarily an undergraduate institu¬ 
tion with a strong commitment to teaching. 
Scholarship and professional activities are 
strongly encouraged. The successful candi¬ 
date is expected to establish an active re¬ 
search program in some specialization of 
Computer Science. A Ph.D. in Computer 
Science or closely related field is required. 

Send application with resume to Dr. John 
S. DaPonte, Chairperson, Computer Sci¬ 
ence Department, Southern Connecticut 
State University, 501 Crescent Street, New 
Haven, CT 06515. 

Review of candidates will begin on Octo¬ 
ber 1, 1992. SCSU is an AA/EO employer. 
Women, minorities, the handicapped and 
veterans are encouraged to apply. 


SOFTWARE JOBS ABROAD 

The International Computer Professional 
Associaton provides you with the worldwide 
contacts and up-to-the-moment information 
you need to find an exciting software assign¬ 
ment in Paris, London, and many other 
cities around the world. For more informa¬ 
tion about this new network of international 
opportunities call us at (415) 695-7618, 
24 hours/day. 


August 1992 
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THE UNIVERSITY OF TENNESSEE 
AT CHATTANOOGA 

Applications are invited for an anticipated 
position in Computer Science at the rank of 
Assistant Professor. Applicants must have 
a Ph.D. in Computer Science. Applicants 
with experience and/or training in Software 
Engineering are especially encouraged but 
those with interests in other areas are also 
welcome. Send applications to: 

Dr. Jack Thompson, Head 
Computer Science Department 
School of Engineering 
University of Tennessee at Chattanooga 
615 McCallie Avenue 
Chattanooga, TN 37403 
Phone (615) 755-4349 
BitNet Address is: cfjt@utcvm 
The University of Tennessee at Chatta¬ 
nooga is an equal employment opportunity/ 
affirmative action/Title IX/Section 504 in¬ 
stitution . 


SOFTWARE ENGINEER 

Analyze retail procedures to design, de¬ 
velop, enhance, test and implement retail 
POS systems and software using experience 
w/ICL Retail 67 application software; DRX, 
DMFI1I, Retail 7 and 8/200 operating sys¬ 
tems; 9518 POS terminals, DRS20, System 
25 hardware; 2780/X25 telecommunica¬ 
tion protocols, HSI interface and periph¬ 
erals, including scanners, 9518 slip printers 
and magnetic strip readers. Develop and 
specify logical/mathematical operations to 
be performed using experience w/CIS 
COBOL and CIP software development 
tools. Requirements: 4 years experience in 
job offered; OR 5 years experience as Pro¬ 
grammer Analyst with experience described 
above; OR B.S. in Computer Science AND 
2 years experience in job offered; OR B.S. in 
Computer Science AND 3 years experience 
as Programmer Analyst with experience 
described above. 40 hr/wk; 9-5; $43,750/ 
yr. Job site and interview: Irving, TX. Apply 
at the Texas Employment Commission, Dal¬ 
las, Texas, or send resume to the Texas 
Employment Commission, TEC Building, 
Austin, TX 78778, J.O. #6718204. Ad Paid 
by an Equal Employment Opportunity 
Employer. 


SENIOR SYSTEMS ANALYST 

Needed to plan, schedule and direct pre¬ 
paration of computer programs to process 
data and solve problems. Design, develop, 
test and implement on-line applications for 
magazine fulfillment in an IBM MVS/ESA 
environment within MACRO and Com¬ 
mand level CICS. Consult with manage¬ 
ment, users and analysts to specify program 
requirements, identify problems, suggest 
changes and estimate project effort and cost. 
Write computer processable code from data 
flow charts. Develop a TSO/ISPF environ¬ 
ment for COBOL-2, BAL and VSAM using 
on-line debugging tools such as Intertest. 
Revise or direct revision of existing programs 
to improve efficiency and/or enhance func¬ 
tion for new requirements. Prepare or direct 
preparation of documentation for developed 


systems and subsequent revisions including 
objectives, Requirements, user manuals, de¬ 
sign documentation. Train analysts and pro¬ 
grammers in design and coding techniques. 

Master of Science degree in Electronic 
Engineering required from U.S. or equi¬ 
valent from foreign university. Five years ex¬ 
perience required in the position offered or in 
the related occupation of Systems Specialist. 
Also required are: 

• Strong analysis and computer design skills 

• Strong skills in COBOL-2 and BAL, 
CLIST and MVS JCL 

• Good working knowledge of file manipu¬ 
lation utilities like File Aid and Easytrieve 

• Strong CICS development knowledge 
and debugging skills using Intertest 

• Excellent knowledge of VSAM 

• Complete command of using TSO under 
IBM MVS/ESA 

• Good written and verbal communication 
skills 

Salary $46,970 per year; 40 hour work 
week with no overtime. 

All interested applicants send resume to: 
Ms. Pat Ganno, Job Order #0630693, Job 
Service of Florida, P.O. Box C, Clearwater, 
FL 34618-4090. 


DEVELOPMENT ENGINEER 

Master in Electrical Engineering or Com¬ 
puter Engineering with strong background in 
Computer Science (9 hours course work); or 
Master in Computer Science with strong 
background in Electrical Engineering (9 
hours course work) required. To develop in¬ 
tegrated electromechanical and software 
systems for 3D imaging and modelling for 
petroleum exploration. To develop real-time 
data acquisition and processing system as 
well as imaging system for the processing 
and analysis of seismic distribution data. 
Must be knowledgeable in Digital Image Pro¬ 
cessing, and Real-Time Data Acquisition 
and Processing (3 hours course work or 
1 year hands-on experience in each area). 
$36,000.00/yr., 40-hrs. wk. Must be U.S. 
worker to qualify. Apply at Texas Employ¬ 
ment Commission, Houston, Texas, or send 
resume to the Texas Employment Commis¬ 
sion, TEC Building, Austin, Texas 78778, 
J.O. #6342905. Ad Paid by An Equal 
Employment Opportunity Employer. 


SOFTWARE ENGINEER 

Analyze, design, program and modify cen¬ 
tral software for the AXE digital switching 
system’s SS7 product and CLASS feature 
applications in the area of Common Chan¬ 
nel Signalling. Perform function block de¬ 
sign, coding and testing of Automatic Code 
Gapping function for Calling Name Delivery 
Class Feature in accordance with client re¬ 
quirements. Conduct development, imple¬ 
mentation and support of testing tools and 
methods of AXE digital switching systems. 
Requires a Bachelor’s degree in Computer 
Science or Electrical Engineering and one 
year of experience in job offered or one year 
of directly related telecommunications soft¬ 
ware design engineering experience with 
digital central office switching equipment. In¬ 


cluded in one year experience, must have at 
least one year in structure design methods 
and real time systems, PASCAL computer 
language, protocols including X.25, BX.25 
and OSI7 Layer Model data communication 
system and use of protocol analyzers. Forty 
(40) hour work week. $39,995.00 per year. 
Apply at the Texas Employment Commis¬ 
sion, Dallas, Texas, Job Order #6687393 
or send resumes to the Texas Employment 
Commission, TEC Building, Austin, Texas 
78778, Job Order #6687393. Ad paid by an 
Equal Opportunity Employer. 


SOFTWARE ENGINEER 

Software development for fibre optic swit¬ 
ches and personal computers using Motorola 
MC 69xx and Intel i8086/i80386 micropro¬ 
cessors. Provide technical support for man¬ 
agement in the development of handwriting 
recognition and image processing software 
products. Interface with computer scientist 
and electrical engineers who are developing 
handwriting recognition and image process¬ 
ing systems for personal computers. 40 
hr/wk, 9-5, $45,000/yr. B.S. in Computer 
Science or Electrical Engineering and two 
years experience in a related occupation as 
a software engineer. Applicant must have 
proven (1) experience in software design 
using assembler language for Intel i8086/ 
i80386 and Motorola MC 68xx. micropro¬ 
cessors (2) experience in the development of 
handwriting recognition software for per¬ 
sonal computers (3) experience in the devel¬ 
opment of image processing software for 
personal computers. Send resume and proof 
of legal authority to work in the U.S. to 
Colorado Department of Labor and Employ¬ 
ment, 600 Grant Street, Suite 900, Denver, 
CO 80203-3528, Attn: Employment Pro¬ 
grams and refer to order number CO4155902. 


YALE UNIVERSITY 

The Department of Electrical Engineering 
invites applications for a faculty position at 
the Assistant or Term Associate Professorial 
level in VLSI system design, computer ar¬ 
chitecture, parallel processors, and other 
areas of computer engineering. Applicants 
should have a Ph.D. in Electrical Engineer¬ 
ing, Computer Science, or closely related 
field, and should exhibit outstanding re¬ 
search accomplishments and a commitment 
to teaching. Close collaboration with the 
existing computer engineering group in the 
Department and interaction with the Depart¬ 
ment of Computer Science are desired. Pre¬ 
ferred candidates should also have a strong 
interest in other programs in the Depart¬ 
ment, including microelectronics, systems 
science, and signal processing, and would be 
expected to contribute to joint research ac¬ 
tivities. Applications are accepted until 
October 30, 1992. Please send resume, in¬ 
cluding names, addresses, and telephone 
numbers of at least three references to: Pro¬ 
fessor T.P. Ma, Chair, Department of Elec¬ 
trical Engineering, Yale University, 15 Pro¬ 
spect Street, New Haven, CT 06520-2157. 
Yale University is an affirmative action, 
equal opportunity employer. 
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UNIVERSITY OF MIAMI 
Department of Electrical and 
Computer Engineering 

The Department of Electrical and Com¬ 
puter Engineering invites applications for 
a tenure-track faculty position at the 
Assistant/Associate Professor level. Ap¬ 
plicants are expected to have a strong back¬ 
ground in computer networks. 

Qualifications include a Ph.D. degree in 
computer science or computer engineering, 
and the ability of initiating research projects, 
attracting external funding, and teaching 
undergraduate and graduate courses. Salary 
will be commensurate with rank and 
experience. 

The University is located in Coral Gables, 
a suburb of Miami, Florida. Applications 
should be sent with the names of three 
references to: Dr. Tzay Y. Young, Chair¬ 
man, Dept, of Electrical and Computer Engi¬ 
neering, University of Miami, P.O. Box 
248294, Coral Gables, Florida 33124. 

The University of Miami is an equal op¬ 
portunity/affirmative action employer. 


UNIVERSITY OF UTAH 
Director 

Utah Supercomputing Institute 

Applications and nominations are invited 
for the position of Director of the Utah 
Supercomputing Institute at the University of 
Utah. We seek a candidate with the highest 
credentials in High Performance Computing 
who will be able to direct the Institute, col¬ 
laborate with faculty in obtaining extramural 
support, and develop industrial partnerships 
and applications in High Performance Com¬ 
puting. It is anticipated that the successful 
candidate will qualify for auxiliary faculty ap¬ 
pointments in one or more academic depart¬ 
ments. A Bachelors degree or equivilancy in 
Science or Engineering is required (A Ph.D. 
is strongly preferred), with expertise in com¬ 
putational science. Furthermore, applicants 
should have a minimum of 5 Years previous 
research and administrative experience. 
Familiarity with National Supercomputer 
Centers and funding agencies is highly desir¬ 
able. Computational facilities at the Utah 
Supercomputing Institute include an IBM 
3090/600s Supercomputer and an IBM 
RISC station cluster. 

Please send your curriculum vitae and 
supporting information to Ms. Shirley Wat¬ 
kins, Personnel Department, 101 Annex, 
University of Utah, Salt Lake City, Utah 
84112. Applications will be accepted until, 
August 31, 1992, or until a qualified can¬ 
didate is identified. 

The University of Utah is an Equal Oppor¬ 
tunity/Affirmative Action Employer. 


RESEARCH DIRECTOR 
Cooperative Research Centre for 
Distributed Systems Technology 
Brisbane, Australia 

An opportunity to found and lead a US$40 
million R & D programme creating products 
and tools for tomorrow’s open distributed 
systems. 

The Cooperative Research Centre for Dis¬ 


tributed Systems Technology is being 
established under an Australian Govern¬ 
ment programme with initial Government 
and Industry funding of US$40 million over 
7 years. It will develop technologies that will 
form infrastructure for global distributed in¬ 
formation systems and services. The Centre 
requires a Research Director who will lead 
Industry-oriented and basic R&D activities in 
architectures, databases, software tools and 
in management, security and performance. 

Five leading universities in Australia have 
joined forces with transnational and local in¬ 
formation technology companies, govern¬ 
ment and Australian telecommunications 
and defense research organizations to form 
the Centre. It will operate as a company, 
closely linked to its participants, and head¬ 
quartered on The University of Queensland 
campus. The Research Director may also 
be appointed as Chief Executive of the 
company. 

The Research Director will be a leading 
researcher with an international reputation in 
the field, a proven record working with in¬ 
dustry, and experience in planning, organiz¬ 
ing and executing a research programme in¬ 
volving multiple research teams from varied 
backgrounds. 

Success in this foundation position will 
bring wide recognition and involvement in 
internationally significant projects, standards 
activities and organizations. Terms and con¬ 
ditions will be internationally competitive for 
such positions. 

You are invited to discuss the position and 
request further information by contacting: 

Rob Cook on 61 7 365 4321 or cook@ 
citr.uq.oz.au (Fax61 7 365 1399); Professor 
Andrew Lister on 61 7 365 9168 or lister@ 
cs.uq.oz.au. 

Written applications quoting reference no. 
30992 should be addressed to DSTC, The 
University of Queensland, Qld 4072 Aus¬ 
tralia. Applications close on 31st October 
1992. 


PROGRAMMER ANALYST III 

Programmer Analyst III needed to design 
and develop graphical workstations on the 
Macintosh to display and analyze engineer¬ 
ing data retrieved from IBM and VAX main¬ 
frames, and from various CAD platforms 
utilizing C++, C and Assembly languages 
and heavy use of the Macintosh Operating 
System Toolbox. Analyze data to determine, 
recommend, and plan computer equipment 
configurations and modifications to the 
existing equipment and systems. Study the 
existing data handling systems to evaluate ef¬ 
fectiveness and develop new systems as re¬ 
quired. Specify in detail the operations to be 
performed by various equipment units and 
the operations to be performed by personnel 
using the system. Program complex prob¬ 
lems and clearly defined segments of large 
complex programs and assist with tests and 
in making revisions to eliminate errors using 
Macintosh computer system and C program¬ 
ming language. Requires a Bachelor’s de¬ 
gree in Computer Science or Electrical Engi¬ 
neering and two years experience in job 
offered or two years as software engineer. 
Must have knowledge of: developing and 
designing import/export file format trans¬ 
lators for the CAD/Graphics file formats 


DXF (Drawing Exchange File Format); IGES 
(Initial Graphics Exchange Standard); vari¬ 
ous Macintosh development environments; 
debuggers and tools such as MPW, THINK, 
SADE, MacsBug, TMON, ResEdit; develop 
commercial Graphics/CAD/CAE software 
packages on the Macintosh using the Macin¬ 
tosh ToolBox, Macintosh Operating System 
Interface routines, C, C++, Pascal 
Assembly M68xxx. 40 hours per week. 
$788.54 per week. Apply at the Job Service 
of Florida, 1307 North Monroe Street, 
Tallahassee, Florida 32303, Re: Job order 
number FL-0628517. Ad paid by an Equal 
Employment Opportunity Employer. 


COMPUTER ENGINEERING FACULTY 

The Department of Electrical and Com¬ 
puter Engineering has tenure track openings 
in its computer engineering program. Can¬ 
didates with an earned doctorate, a strong 
commitment to teaching, and demonstrated 
ability to conduct significant research in such 
areas as VLSI design systems, computer ar¬ 
chitecture, computer networks, parallel pro¬ 
cessing or intelligent systems are invited to 
apply. NJIT’s campus is networked and 
computing-intensive. A state-of-the-art 
Microelectronics Fabrication Center, an 
Electronic Imaging Center and the inter¬ 
disciplinary Center for Manufacturing Sys¬ 
tems are examples of research foci. Rank 
and tenure dependent upon qualifications. 
Send resume, statement of teaching and re¬ 
search interest, and three references to Per- 
sonel Box-CEF. 

NJIT does not discriminate on the basis of 
sex, sexual orientation, race, color, handicap, 
religion, national or ethnic origin, veterans’ 
status, lifestyle or age in employment. 

New Jersey Institute of Technology 

University Heights 

Newark, NJ 07102. 


COMPUTER SYSTEMS ENGINEER 

Research, design and develop computer 
system for design engineering department of 
a rechargeable battery manufacturer. 
Analyze software and user requirements for 
standardizing the battery design procedures. 
Develop, test and document software pro¬ 
grams using the latest software engineering 
techniques. Coordinate with mfg/design 
personnel to provide exchange of design in¬ 
formation. Monitor CAD procedures and 
upgrade hardware/software to keep CAD 
state of the art. Research, plan and develop 
standardized method for flow of product 
design information by updating computer 
setup. Maintain and/or upgrade current PC 
network; provide user’s support and monitor 
system performance. Requires MS in Engi¬ 
neering and two years programming and 
battery design experience, 1 year experience 
with mainframe MRP system, knowledge of 
CAD software, and experience with PC Net¬ 
works. Apply at the Texas Employment 
Commission, El Paso, Texas or send resume 
to the Texas Employment Commission, TEC 
Building, Austin, Texas 78778, J.O. 
<'6717817. Ad Paid by an Equal Opportunity 
Employer. 
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BOOK REVIEWS 


Editor: Alan Kaminsky, Harris Corporation, 1680 University Avenue, Mail Stop 17, Rochester, NY 14610 
(716) 473-8237, ext. 8237; Internet ark@cs.rit.edu;Bitnet arkics@ritvax 


Compared to What? An Introduction to the Analysis of Algorithms 

Gregory J.E. Rawlins (Computer Science Press, New York, 1992, ISBN 0-7167-8243-X, 536 pp., $49.95) 


I have been teaching algorithms and 
data structures for several years. 

While I am always impressed when 
some brave author dares to write yet 
another book on this over-popular 
topic, I usually start reading with low 
expectations. 

This book covers the classical top¬ 
ics: algorithm design and analysis, 
searching, selecting, sorting, graph 
algorithms, arithmetic, NP-complete- 
ness. Nothing really exciting, you 
might think. 

Yet Rawlins’s book is superb — 
primarily because a beginner can read 
and understand it independently of 
any lecture or prerequisite back¬ 
ground. Most often, I find that text¬ 
books are unreadable until you’ve 
been taught the subject. Only then 
can you succeed in reading on your 
own with real understanding. (As a 
teacher, I would tend to add, “Fortu¬ 
nately!” What would we be paid for 
otherwise?) 

Let’s survey chapter three on select¬ 
ing — my favorite. In order, its topics 


are finding the best (that is, the max) 
element in a linear array, finding the 
second best, the best and the worst, 
and the ith best — a great progres¬ 
sion. The writing is always clear, and 
it is full of humor as it challenges the 
reader. For example, in the middle of 
the text, Rawlins will ask, “Do you 
really believe this?” He answers both 
simple and hard questions, then theo¬ 
rizes a bit (for example, he discusses 
partitions and variations on the mod¬ 
el). Finally, in a nice “coda,” he sum¬ 
marizes what the chapter teaches on 
selection methods and the scope of 
their applicability. 

Of course, this book will not replace 
your favorite encyclopedia. Introduc¬ 
tion to Algorithms by Cormen, Leiser- 
son, and Rivest (MIT Press, 1990) 
remains a must. More experienced 
users will still go back to Knuth’s 
three-volume The Art of Computer 
Programming (Addison-Wesley, 1969) 
from time to time. But in getting start¬ 
ed, you can’t do better than to read 
Rawlins’s book first. 


I have to temper my enthusiasm 
somehow. I found the chapter on 
graphs too dense. In fact, it may actu¬ 
ally require some external help to 
read. 

At the other extreme, the chapter 
on NP-completeness is too superficial. 
I understand the need to introduce 
NP-completeness, but can hardly 
imagine why you would speak of it 
without including a proof of an exam¬ 
ple problem that is indeed NP-com- 
plete (for example, the satisfiability 
problem in the text). 

But these are not serious reserva¬ 
tions. I have a large library related to 
algorithm design but will happily add 
this book to the few that I use for 
teaching. And if I were younger, I 
would be grateful to the author for 
giving me such a fine opportunity 
to become a self-made algorithm 
designer. 

Yves Robert 

Ecole Normale Superieure de Lyon 

Lyon, France 


Data Compression, Third Edition 

Gilbert Held (John Wiley and Sons Ltd., Chichester, England, 1991, ISBN 0-471-92941-7, 301 pp., $49.95) 


Text compression is made practical 
by a variety of techniques, but it still 
requires MIPS at both the transmitter 
and the receiver, and cooperative data 
most of all. Gilbert Held’s text, now in 
its third edition, provides a guided 
tour of the simplest, most easily ap¬ 
plied techniques. Most of the book’s 
heuristics do not require mathemati¬ 
cal rigor; where they do, the reader is 
referred to background material that 
is complete but somewhat dated. 

Dated references and examples 
might be expected in a third edition, 
but typos, mathematical errors, and 
awkwardly formatted tables are sur¬ 
prising. Further, the book omits 


speech, audio, and image compression 
and would more correctly be titled 
Text Compression. A section titled 
“Relative Encoding” (also known as 
differential encoding) is as close as 
the book comes to a discussion of 
nontext, nonfax source material. 

Data compression is motivated by 
reductions in cost and time. Methods 
that double the effective capacity of 
disk drives or halve the time of mo¬ 
dem transmission quickly pay for 
themselves. Held develops good intro¬ 
ductory examples of the interrelation¬ 
ships between communication proto¬ 
cols and compression. His derivation 
of a protocol’s maximum useful buffer 


size for a given channel error rate is 
especially instructive. However, other 
discussion are dated (for example, the 
discussions of Baudot and binary-cod¬ 
ed decimal (BCD) character encoding 
and of forms-mode operation). 

Descriptions of null suppression, 
bit-mapping, and run-length encoding 
with five other less-used but equally 
simple techniques include individual 
reviews of their efficiency, implemen¬ 
tations, and limitations. Held also 
demonstrates compression methods in 
a programming language — namely, 
Basic. The sample programs would be 
easier to read (and to use) if they 
were written in C or Pascal. 
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The chapter on statistical encoding is 
the most interesting. It opens with a 
brief introduction to information theo¬ 
ry and moves on to Huffman coding. It 
presents a good example of how to 
construct a minimum-variability Huff¬ 
man code and includes helpful rules of 
thumb: 

• When you move a combined state 
as high as possible, it reduces the vari¬ 
ability of the resulting Huffman code. 

• Use Shannon-Fano codes when the 
variance in character probabilities is 
large. 

• MNP 5 encoding usually results 

in a compression ratio between 1.5 and 

2.0. 

• MNP 7 compresses MNP 5 by 
another 15 to 25 percent. 

• V.42bis compresses MNP 7 an 
additional 10 to 20 percent, though 
some modems do not support a large 
enough codebook to achieve this incre¬ 
mental compression. 


A discussion of the Lempel-Ziv al¬ 
gorithm is prefaced by a good section 
on adaptive, fixed-length dictionary 
compression and string compression. 
The treatments of Lempel-Ziv and 
V.42bis are brief, but adequately ref¬ 
erenced. 

The final three chapters provide an 
important but easily overlooked per¬ 
spective: Where and how does data 
compression fit into systems? Chapter 
five discusses Datanalysis, a unique 
program that provides several mea¬ 
sures of compressibility for individual 
files. Although the program itself is 
archaic, the underlying message can¬ 
not be overstated: The more effective¬ 
ly users characterize typical data, the 
higher the expected compression ra¬ 
tio. Chapter six presents relevant soft¬ 
ware design considerations (for exam¬ 
ple, buffer sizes and timing estimates), 
and Chapter seven reviews software 
and hardware products that employ 
data compression. 


The appendixes especially show the 
book’s age. Appendix A contains 
Fortran-IV listings for Honeywell 66/ 
80’s and DECsystemlO’s, as well as 
occasional humor: “Due to an unex¬ 
plainable bug in the system . . . the 
starting values had to be inflated by 
16.” The references contain no publi¬ 
cation more recent than 1978, though 
a section titled “Further Reading” in¬ 
cludes material as recent as 1989. 

Heuristics are useful in the infancy 
of a field, but data compression is now 
mature enough to warrant a more 
rigorous treatment. More technical 
readers may want to consider Text 
Compression (Timothy Bell et al., 
Prentice-Hall, 1990) or Data Com¬ 
pression: Methods and Theory (James 
Storer, Computer Science Press, 

1988), if heuristics are not enough. 

Al Wegener 

Studer Editech Corporation 

Menlo Park, California 


Logic and Information 

Keith Devlin (Cambridge University Press, New York, 1991, ISBN 0-521-41030-4, 308 pp., $32.95) 


This book reports progress toward 
a mathematical theory of information. 
The author wants to go beyond Claude 
Shannon’s study of the signal content 
of information by designing an applied 
mathematical system — namely, an en¬ 
hanced mathematical logic — to pro¬ 
cess information artificially. 

As a set theorist and a logician, Dev¬ 
lin did much of this research at the 
Center for the Study of Language and 
Information at Stanford University. 
One of the offices in that laboratory 
belongs to John McCarthy, who is 
credited with coining the term artificial 
intelligence and developing the well- 
known Lisp language. As might be ex¬ 
pected, natural language processing for 
Al is important here. 

Traditional logic uses first-order 
predicate calculus. It is considered in¬ 
adequate for processing information in 
the way people handle common-sense 
problems. The author wants instead to 
build a sort of metamathematics. He 
begins by defining infons as units of in¬ 
formation. (More precisely, he regards 
infons as mathematical equivalence 
classes.) Situations correspond roughly 
to events in space-time, but go beyond 
that; in fact a proper definition is con¬ 
sidered impossible at present. These 
definitions become the basis for ex¬ 
ploring topics like situation theory, 
constraints in meaning, mental states, 


perception with action, and situation 
semantics. 

The style is not that of a standard 
textbook. Instead it addresses a math¬ 
ematically minded scientific reader 
and includes many pedagogical illus¬ 
trations from mathematics, physics, 
and computer science. The author is 
an entertaining writer and clear ex¬ 
positor of a new and difficult subject. 
He strews discussions of number sys¬ 
tems, space-time, causality, robotics, 
and many other topics throughout the 
book. These discussions enhance the 
book’s readability, even though they 
involve some mathematical and logi¬ 
cal symbolism. 

Devlin draws fruitful analogies to 
the development of number systems. 
Primitive humans were able to make 
one-to-one correspondences between 
sets of Objects, but the abstract whole 
number system was not properly de¬ 
fined until the 19th century. Even 
Blaise Pascal would not accept nega¬ 
tive numbers. The Argand diagram 
helped with the acceptance of abstract 
complex numbers. Likewise, it may 
take some time to accept situations as 
abstract objects in their own right. 

Scientific methods evolve, and tra¬ 
ditional approaches are eventually su¬ 
perceded. This book is based on the 
idea that existing mathematics may 
not be sufficient to set up frameworks 


for studying new scientific problems. 

In fact, physicists and applied mathe¬ 
maticians have begun moving in new 
directions of pure mathematics. For 
example, applied mathematics such as 
knot theory and gauge theory (the lat¬ 
ter is connected with relativity and el¬ 
ementary particle physics) have 
strongly influenced pure mathemati¬ 
cians in researching the geometry of 
three- and four-dimensional mani¬ 
folds, respectively. (The author cites 
Sir Michael Atiyah’s remarks con¬ 
cerning this.) Even a new discipline 
like computer science is beginning to 
have repercussions on mathematics 
and physics, as we see in the study of 
chaos and nonlinear dynamics. 

I think this book can benefit com¬ 
puter scientists and mathematicians 
who are curious about the digital com¬ 
puter’s future, the processing of infor¬ 
mation, and the capabilities of Al. 

The author points out that the book 
was released at an early stage in the 
development of the subject. He has 
corresponding disappointments as 
well as hopes for a more complete 
theory in the future. We should look 
forward to provocative long-range 
developments. 

A.C. Manoharan 

University of Central Oklahoma 

Edmond, Oklahoma 
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Computer science: The forgotten science 


A cursory examination of some of 
the major sources of science articles 
for general public consumption re¬ 
veals a dangerous lack of articles on 
computer science. If you review Dis¬ 
cover magazine, Science News, and the 
weekly science section of the New 
York Times, the only articles you’ll 
find about computing topics will be 
those that describe new computers or 
new software. 

These organs all contain numerous 
articles about astronomy, the biologi¬ 
cal and medical sciences, chemistry, 
geology, and physics. There are even a 
few articles about mathematics! Scien¬ 
tific American does cover computer 
science fairly well with a monthly col¬ 
umn on recreational uses of comput¬ 
ers. The column often explores tools 
such as neural networks used by com¬ 
puter scientists. And, Scientific Amer¬ 
ican has had some special issues de¬ 
voted primarily to computer science. 

But, I think you would have to 
agree that the overall coverage of 
computer science in the major printed 
sources of information for the public 
is much, much less comprehensive 
than for other sciences. 

Even the journals of general science 
neglect computer science. The AAAS 
Science journal of the American Asso¬ 
ciation for the Advancement of Sci¬ 
ence, for example, has articles on the 
biological and medical sciences, chem¬ 
istry, and physics in every weekly is¬ 
sue. But, as far as computer science 
goes, it’s a good year when four or 
five articles on the subject appear. 


Impact of computer science. Com¬ 
puter science has had a significant im¬ 
pact on human life during the last half 
of the twentieth century. Its impact ri¬ 
vals that of the other sciences. More¬ 
over, computer science’s impact shows 
every sign of being even more signifi¬ 
cant during the next 50 years. Maga¬ 
zines and newspapers try to keep citi¬ 
zens informed about astronomy or 
human biology; those same citizens 
need to be equally informed about 
computer science. 

Computer science includes many 
activities that are as important to the 
average citizen as “bucky balls” — a 
new class of molecules — or the latest 
theories on galaxy formation. For ex¬ 
ample, where are the articles explain¬ 
ing the recent advances in automatic 
speech recognition or in software de¬ 
velopment? What about robotic vi¬ 
sion, animation, or parallel processing 
architectures? How about theoretical 
questions concerning the limitations 
of algorithms or the p = np question? 

Where in the popular press is there 
a discussion of the successes and fail¬ 
ures of the Japanese Fifth-Generation 
project or of Europe’s ESPRIT? Why 
not an article exploring the techniques 
developed for hypertext and hyperme¬ 
dia and the implications of these me¬ 
dia? Recent advances in expert sys¬ 
tems and subsymbolic artificial intel¬ 
ligence deserve popular explanations 
as well. You could easily add to this 
list. 

The implications of this relative ne¬ 
glect of computer science are very se¬ 


rious for those in computer science 
and computer engineering, as well as 
the general public. The computer sci¬ 
ence field continues to suffer from a 
lack of talent. More high-caliber, 
hard-working students need to pursue 
computer science as a major and as a 
career. 

If the only computer-linked phe¬ 
nomena the public regularly hears 
about deal solely with new technolo¬ 
gy, the excitement and adventure of 
computer science cannot attract new 
talent to the field. The widespread 
trend of falling computer science en¬ 
rollments during the last decade will 
continue unless the attractive aspects 
of computer science and computer en¬ 
gineering are publicized widely and 
frequently. 

What can be done? All of us can 
participate in an effort to rectify this 
situation. We should be contacting the 
publishers and writers of the popular 
magazines to urge them to write arti¬ 
cles on computer science and engi¬ 
neering topics. We should inform 
them of interesting work that we or 
our colleagues are doing. 

Those of us with a flair for writing 
could write articles for the press. And, 
we should encourage students we 
know who have writing talent and 
computing interest to pursue careers 
writing for one or more of the maga¬ 
zines. 

If the United States is to continue 
as a world leader in developing and 
using computer technology, it must re¬ 
main a world leader in computer sci¬ 
ence and computer engineering. The 
popular magazines and journals that 
cover the sciences must include fre¬ 
quent, perceptive articles on comput¬ 
ing. Computing must be understood 
as more than just an adjunct to the 
other sciences, engineering, business, 
the arts, and government. 

Kenneth Magel 

North Dakota State University 

kmagel@plains.nodak.edu 


“The Open Channel” is exactly what the name Implies: a forum for the free ex¬ 
change of technical ideas. Try to hold your contributions to one page maximum in 
the final magazine format (about 850 words). 

We’ll accept anything (short of libel or obscenity), so long as it’s submitted by a 
member of the IEEE Computer Society. If it’s really bizarre, we may ask you to 
get another member to cosponsor your contribution. 

Send everything to Will Tracz at the address above. 
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CALL FOR PAPERS 



IEEE/ACM International Conference on 

Developing & Managing 
Intelligent System Projects 

March 29-31,1993 
Washington, DC 


Expert systems, neural networks, fuzzy logic, genetic algorithms, and other technologies are important for the practical application of 
intelligent systems. At this conference, managers, developers, scientists, engineers, and contractors will exchange ideas about putting these 
technologies to work for solving today's complex problems. Participants will share experiences and practical guidelines for realizing the 
potential of intelligent systems in government, business, and industry. 


Topics of Interest: 

• Expert systems and knowledge 
engineering 

• Neural networks 

• Object-oriented techniques 

• Hypermedia and multimedia 
technologies 

• Case-based reasoning 

• Integrated and embedded systems 

• Fuzzy systems 


• Automated knowledge acquisition 

• Genetic algorithms 

• Educational and training issues 

• Future directions in research and 
development 

• Project selection and cost justification 

• Project management and lifecycle 

• Financing intelligent system projects 


• Measuring productivity and payback 

• System maintenance and enhancement 

• Developer skills needs and training 

• User and organizational issues 

• Risk management and legal issues 

• Validation and verification 

• Certification of knowledge engineering 

• Case studies and lessons learned 


auDmining rapers; 

Authors should submit full papers to Mark Gembicki, Program Chair, postmarked no later than November 1,1992. Each submission must 
include one cover page and four copies of the complete manuscript. The cover page should include the title of the paper, name(s), 
affiliations(s), complete address(es) of co-authors,and telephone number and e-mail address of the principal author. 


The four copies of the manuscript should include: 

• Title page with abstract. 

• Complete English-language text, not to exceed 20 double-spaced pages, including 

illustrations. , 

• Paper submission deadline: November 1, 1992. 

• Notice of acceptance will be sent to the principal author by December 1,1992. 

• Send papers to Mark Gembicki, TCS, 47 Randall Street, Annapolis, MD 21401. 


Please note that only papers presented at the 
conference will be included in the proceedings. 

All presenters are expected to pay for their own 
conference registration. 


Conference Chair 

Larry Medsker 

The American University 

Conference Co-Chair 

Janice Sipior 
Villanova University 


Finance Co-Chair 

Sue Conger 

CUNY, Baruch College 

Tutorial Chair 

Deborah Finley 
Interactive Communications 


International Activities Chair 

Jerry Feinstein 
MITRE 

Special Programs Chair 

Jesse Bemley 
JEF, Inc. 


sponsored by: 

IEEE Computer Society 
Technical Committee on 
Expert Systems 
and the 


Program Chair 

Mark Gembicki 
TCS 

Program Co-Chair 

George Kasper 
Texas Tech University 

Panel Chair 

Tom Beckman 
Internal Revenue Service 

Panel Co-Chair 

Edward Garrity 
Canisius College 

Finance Chair 

Steven Oxman 
OXKO Corporation 


Tutorial Co-Chair 

Michael Gray 

The American University 

Publicity Chair 

Susan Menke 

Government Computer News 

Publicity Co-Chair 

Rodger Knaus 
Instant Recall 

Corporate Chair 

Dennis Copeland 
MITRE 

Corporate Co-Chair 

Linda Volonino 
Canisius College 


Technical Committee Sponsorship 

Harry Siegal, IEEE CS 
JAYCOR 

Elias Awad, ACM 
University of Virginia 


ACM Special Interest 
Group on Business Data 
Processing 


Standing Committee 

Jay Liebowitz 

The George Washington University 

Past Program Chair 

Efrain Turban 

Eastern Illinois University 


UIEEE Computer Society 
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